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METHOD, COMPUTER PROGRAM 
PRODUCT, AND SYSTEM FOR CLIENT-SIDE 

DETERMINISTIC ROUTING AND URL 
LOOKUP INTO A DISTRIBUTED CACHE OF 

URLS s 

BACKGROUND OF THE INVENTION 

1. The Field of the Invention 

The field of the present invention is that of the proxy 
servers used in connection with accessing data over the 10 
World Wide Web ("WWW") through the Internet or other 
Wide Area Network ("WAN"). More particularly, the 
present invention involves an array of multiple proxy servers 
configured together to act as a single distributed cache of 
information identified through the use of Uniform Resource 1S 
Locators ("URL"). Specifically, the invention treats intelli- 
gent or enabled clients that may directly access a desired 
URL data object from a particular proxy server in a proxy 
server array having the URL requests laterally routed or 
transferred amongst array members. 20 

2. Present State of the Art 

Generally speaking, the concept of a "cache" or "caching" 
as used in computer terminology and applications typically 
means making a more accessible copy of some piece of data 25 
for a performance advantage. For example, information that 
is cached is in many instances more accessible than it 
otherwise would be so that processing speed is increased 
since accessing the cached information is quicker. 

Since having excess copies of data can create its own sort 30 
of overhead and because cache size is limited, data is not 
typically retained in a cache indefinitely and will eventually 
be overwritten after a certain amount of time if the cache is 
being fully utilized. This may occur according to a Leased 
Recently Used ("LRU") algorithm, an expiration time, or 35 
any other relevant criteria for a particular application. Cach- 
ing commonly exists at the microprocessor level with 
instruction and data caches so as to avoid excessive access- 
ing of system RAM and may also exist elsewhere in a 
computer system or in a network of computer systems. 40 

Another form of caching is commonly used in relation to 
accessing data or information over the WWW. Auser having 
Internet access can directly receive a URL identified data 
object, such as a web page, and then display it locally on a 
browser. Each time the user receives such a data object, there 45 
is a delay as the Hyper Text Transport Protocol ("HTTP") 
request travels across the Internet to the location identified 
by the URL and the destination server processing the URL 
request responds with the requested data object. Because the 
data object can be quite large, the time to access the data 50 
objects with the HTTP request and response creates a 
significant amount of information traveling over the Internet 
connection causing delays and excess overhead. 

In some organizations, many of the same data objects are 
requested by the various users within the organization. It is 55 
therefore common to introduce a proxy server that will 
receive user access requests from a client application, such 
as a web browser. Referring to FIG. 1, the use of a proxy 
server acting as a cache is shown. A client application 20 will 
direct all URL requests to a proxy server 21 that will serve 60 
as a cache for any information (i.e., URL data objects) 
associated with the URL. Should the proxy server 21 not 
have the URL data object within its cache, it will, in turn, 
make access over the Internet 22 to the destination server 
found within the URL in order to place the data object into 65 
its cache and then respond to the client 20 URL request. 
Thereafter, should another client make a request to the proxy 
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server 21, it can be serviced directly from the cache without 
necessary access over the Internet to the destination server 
found in the URL itself. 

Note that the client 20 can be any software application 
capable of communicating or directing requests to the proxy 
server 21 using the HTTP protocol and would include other 
proxy servers, web browsers, Internet "enabled" 
applications, etc. Furthermore, HTTP requests contain a 
variety of information that can be used to "force" the proxy 
server 21 to access the URL data object over the Internet in 
order to assure that the "freshest" copy has been accessed. 
Such operation of proxy servers and their use as caches are 
generally known in the art for use in servicing HTTP 
requests. 

It should be noted that the term URL may indicate either 
the address of where a data object is originally located and 
accessed, or the data object itself. To distinguish, a URL 
itself would be an address or location of the data object 
whereas a URL data object would be the actual web page file 
that is transmitted across the Internet to the client applica- 
tion. Though the appropriate usage is readily identifiable by 
context, efforts will be made throughout this application to 
distinguish between the two. 

There are benefits of having a proxy server acting as a 
cache for URL data objects. One benefit is that for cached 
items, the total access time for a user is generally reduced 
since the connection between the client 20 and the proxy 
server 21 is typically over a Local Area Network ("LAN") 
rather than having to access the data object over the Internet 
or other Wide Area Network ("WAN"). Another benefit is 
for security purposes so that an organization may have a 
"firewall" to protect itself from unwanted outside penetra- 
tion. 

Larger corporations and other organizations may have 
many proxy servers servicing their needs. It becomes desir- 
able in such situations to harness many proxy servers 
together as a single, logical distributed cache. Ideally, such 
a single distributed cache would have no duplication of URL 
data objects contained therein. Furthermore, a single dis- 
tributed cache should have as little overhead as possible in 
servicing any given URL request that arrives at a member of 
the distributed cache. In other words, the actual URL data 
object may not be residing at the same server that originally 
receives the URL request and some form of forwarding, 
routing, or acquisition of the desired URL data object must 
occur in order to service that original URL request. 

One attempt at creating a such a distributed cache is the 
Internet Cache Protocol ("ICP") that coordinates the activity 
of an "array" of proxy servers. Though ICP allows an array 
of proxy servers to function as a distributed cache, it also has 
some drawbacks as will be explained hereafter. 

Referring now to FIG. 2, the interaction of a client with 
a proxy server array is shown. In such an arrangement, a 
client 23 will contact one of the proxy servers in the array 
24 in order to access URL data objects that are available over 
the Internet 25. Typically, a client 23 is assigned to a 
particular proxy server within the proxy server array 24 and 
may itself be a proxy server. Since the URL data object 
requested by a client may exist in a different proxy server 
than the one contacted, a mechanism or protocol is necessary 
for routing the URL request from the receiving proxy server 
to the appropriate proxy server, or in some other way service 
that URL request. 

Referring now to FIG. 3, proxy server array that is 
organized and configured according to the ICP protocol is 
shown. In the example shown in FIG. 3, a client 26 will 
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direcl HTTP requests to an assigned proxy server 27 that is servers. In an extreme case, each proxy server of the ICP 

part of an ICP proxy server array 28. Assuming that a desired proxy server array 28 could become a redundant mirror of 

URL data object is contained in the distributed cache created the other array members. It would be desirable to have only 

by the ICP proxy server array 28 and located at the proxy one copy of a URL data object existing in the entire 

server 29, a scenario illustrating the operation of ICP is now 5 distributed cache so that the distributed cache may be used 

shown. This scenario will also illustrate a number of prob- to its full capacity. 

lems that make ICP a less than optimal way of creating a Finally, adding or deleting proxy servers from the ICP 

distributed cache. proxy server array 28 may totally disrupt the distribution of 

The URL request will originate at the client 26 and be URL data objects across the entire logical cache. In an 

received by the proxy server 27 as indicated by arrow 30. 1Q extreme case, the distributed cache may be "emptied" upon 

After determining that the desired URL object does not any addition or removal of a proxy server from a proxy 

reside at the proxy server 27 in its local cache storage, a server array. 

query will be sent out to all proxy servers in the ICP proxy what ^ needed is a tru i y distributed logical cache across 

server array 28 as indicated by the query messages path 32. an array of proxy where a given URL data objec , is 

In turn, every other proxy server that receives the query will ^ contained therein at only one location so as to maximize 

give a response back to the proxy server 27 as indicated by cache capac i, y . Furthermore, what is needed is a way to 

the response message path 34. Each individual response will access the proxy the logjcal dis , ri5uted 

indicate whether or not the specified URL data object resides cache or array of proxy servers without making a query to 

at that particular responding proxy server. Note that more each and every proxy S6rver making up the array tnereby 

than one of the proxy servers in the ICP proxy server array 2Q allowing a request received at one proxy server to be directly 

28 may contain a given URL data object. routed to the correct proxy server, or alternatively, an 
For purposes of this example, it is assumed that only the acquisition of the desired URL data object from the correct 

proxy server 29 actually contains the data object and there- pr0 xy server quickly attained. Finally, what is needed is a 

fore the response from proxy server 29 to proxy server 27 way 0 f gracefully migrating cached URL data objects 

would be the only response having an indication that the 25 between the different proxy servers as a result of additions 

desired or requested URL data object exists thereon. Note 0 r removals of proxy servers from the proxy server array 

that for an ICP proxy server array 28 of N proxy servers, that making up the distributed cache that will not require the 

N-l messages were sent out by the proxy server 27 querying reorientation of all URL data objects in the cache. 

for the existence of the URL data object and N-l messages „ „ , „ „ „ 

were sent back to or received by the proxy server 27 in , n SUMMARY AND OBJECTS OF THE 

r • c , 30 INVENTION 

response, thus creating a fair amount of network message i»>u>iium 

traffic and usage of the overall network bandwidth. It is an object of the present invention to enable clients 

Once the proxy server 27 knows where the desired URL with the ability to directly access a proxy server in an array 

data object is located, it will issue a request to get the object of proxy servers that will contain a desired URL data object 

as indicated by the get path 36. Naturally, the proxy server 35 based on processing the URL and proxy array membership 

29 will respond by sending the desired URL data object from information and without making expensive query-response 
the proxy server 29 to the proxy server 27 as indicated by the transaction with each and every proxy array member, 
send object path 38. Now that the proxy server 27 has the It is another object of the present invention to utilize 
desired URL data object, it can respond to the original URL deterministic hashing algorithms to allow consistent and 
request and return that data object to the client 26. 40 predictable identification of a proxy server to be assigned or 

Cache storage redundancy can be seen since the proxy have residing thereon a particular URL data object, 

server 27 will also place the URL data object into its local Additional objects and advantages of the invention will be 

cache such that the same URL data object now exists in both set forth in the description which follows, and in part will be 

proxy server 27 and proxy server 29. Also, network usage obvious from the description, or may be learned by the 

overhead is significant since the total number of messages to 45 practice of the invention. The objects and advantages of the 

allow the proxy server 27 the ability to service the original invention may be realized and obtained by means of the 

URL request for an ICP proxy server array 28 of N proxy instruments and combinations particularly pointed out in the 

servers is 2(N-l)+2 total data messages across the network. appended claims. 

• Given the above scenario, a number of undesirable prob- To achieve the foregoing objects, and in accordance with 
lems exhibit themselves almost immediately. First, by using so the invention as embodied and broadly described herein a 
a query-response scenario to contact all of the proxy servers method, computer program product, and system for client- 
in the ICP proxy server array, a significant amount of side deterministic routing and URL lookup into a distributed 
network resources may be consumed. Additionally, a natural cache of URLs are provided. An enabled client according to 
consequence of the query-response scenario is that the larger the present invention may directly access the correct proxy 
the ICP proxy server array 28 becomes the greater the 55 server in a proxy server array without making expensive 
network overhead for each non-resident URL request, there- query-response transactions or routing the URL data object 
fore adding a negative scalability component to operating an request through multiple proxy servers. 
ICP server array. This means that each addition of another Each proxy server has access to the entire array member- 
proxy server onto the array will in fact increase the amount ship information stored in array membership list. This array 
of communication between the different proxy servers for all 60 membership list is periodically updated and reflects changes 
array members and for each request in order to resolve the in array membership due to additions, removals, or tempo- 
correct location of a desired URL data object. Theoretically, rary unavailability of the various proxy servers that make up 
there may exist an upper limit to the number of proxy servers the array. When changes have propagated through the proxy 
that may be comfortably used in an ICP proxy server array server array, all array membership lists at each proxy server 
28. 65 will contain identical information. 

Another problem is that multiple copies of the distributed The array membership list is also propagated to or oth- 

cache URL data objects exist across the various proxy erwise made available to enabled clients so that array 
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membership information resides al the client itself. Many purpose computing device in the form of a conventional 
different mechanisms exist for getting the information to the personal computer. 

enabled client as those skilled in the art may appreciate. FIG. 5 is a logical diagram showing the operation of a 

When an enabled client generates a URL data object proxy server array configured to form a distributed cache 
request, it uses the array membership list, the URL itself, and 5 where requests are serviced according to the present inven- 
a deterministic hashing function to identify which array tion and an example is given where a request received by 
member should actually hold the URL data object in its local one proxy server of the array may laterally access the proxy 
cache. The request is then serviced by directly accessing the server having the desired URL data object without making 
desired data object from the correct proxy server without queries to all proxy servers in the array, 
making expensive query-response transactions over the net- ,„ FIG. 6 is a flow chart showing the processing steps taken 
work or routing the request through multiple proxy servers. by a proxy server according to the present invention when 
The hashing function operates so as to distribute the cached receiving a URL data object request. 
URL data objects evenly over the entire proxy server array F IG. 7 is a logical diagram showing an array of proxy 

without redundancy so as to more efficiently use the array servers configured to form a distributed cache according to 
capacity. the present invention and an enabled client according to the 

The proxy server identification mechanism works by present invention wherein the client may make the original 
computing a hash value for each server name found in the URL data object request directly to the proxy server within 
array membership list and a hash value for the requested the array that is most likely to contain the desired URL data 

URL. The URL hash value is combined with each member object. 

proxy server hash value to form a combined value. The 2Q FIG- 8 is a flow chart showing the processing steps taken 

proxy server associated with highest of the combined values bv an enabled client for directly assessing the proxy server 

is identified as where the desired URL should reside in local in * proxy server array that is most likely to contain the 

cache. A load factor that assigns some proxy servers pro- desired URL data object. 

ponionately more URL data objects for the local cache is FIGS. 9A-9D show a logical sequence of events that may 

also incorporated in the creation of the combined hash occur in the life of a proxy server array according to the 

values. present invention. 

All information for making a determination as to the FIG. 9A shows the initial state of the proxy server array 

correct proxy server is completely available at an enabled having two proxy servers and each Array Membership List 

client that generates the URL request so that no external ("AML") showing the two active members, 
information is necessary. Furthermore, because of the propa- 30 In FIG. 9B, a third proxy server is added to the array and 

gation of array membership information between the proxy ^ c arra y membership list for all three proxy servers is 

servers, and from there to all enabled clients, the exact same updated to include the newly added proxy server, 
information is used to identify the exact same proxy server In FIG. 9C, one proxy server is temporarily unavailable 

regardless of which enabled client generates the URL due to mechanical failure or other event and the array 

request. 35 membership list of the remaining proxy servers in the array 

These and other objects and features of the present have been marked to indicate that the designated proxy 

invention will become more fully apparent from the follow- server is temporarily unavailable. 

ing description and appended claims, or may be learned by In FIG. 9D, the same proxy server as was unavailable in 

the practice of the invention as set forth hereinafter. FIG. 9C is actually removed from the array and the array 

BRIEF DESCRIPTION OF THE DRAWINGS 40 membershi P lists f rom th e remaining proxy servers are 

updated to indicate the removal of the proxy server from the 

In order that the manner in which the above-recited and 
other advantages and objects of the invention are obtained, FIG, 10 is a flow chart showing the processing steps taken 

a more particular description of the invention briefly by a proxv server or enablcd c , ieDt for randomly aC c essing 

described above will be rendered by reference to specific 45 an array membership Ust from another member of the proxy 

embodiment thereof which are .illustrated in the appended server array lhal represents one form of communicatin g 
drawings. Understanding that these drawings depict only membership information between the different proxy 

typical embodiments of the invention and are not therefore servere and enabled clients 

to be considered limiting of its scope, the invention will be T,, n n ; „ „ „„.,, . . ■ 

• ... . , • j ■. , - c . , rlG. 11 is a flow chart showing the steps taken in order 
described and explained with additional specificity and „ ,„ „ A A „ „„„, „ . 6 v 

a . 1 .u u .u r 1. • • • 5" to add a new proxy server to the proxy server array, 

detail through the use of the accompanying drawings in • „ . L . , 3 

which- FIG. 12 is a flow chart showing the steps taken for 

. - , • . ,. . „ removing a proxy server from the array. 

FIG. 1 is a logical diagram showing the use of a proxy . . , 

server that serves as a cache from which a client may access FIG - 13 *. a loglc f 1 diagram showmg how a P™* xrJel 

desired URL data objects. cc ? rray accordin g 10 lbc P resent invention may be used with 

L r legacy clients and enabled clients. 

FIG. 2 is a logical diagram dlustrating how an array of . , r 

proxy servers may be logically configured to be a single FIG ' 14 15 3 logI ? al diagram shoW1Dg tW ° levels °' P 10 ^ 

distributed cache having a greater capacity. Server "J?*? ^ding to the present invention may be used 

i-, , ma realistic environment where both lateral access and 

FIG. 3 is a logical d.agram showing an array of proxy difec , afe a hshed A ^ ar 

servers that coordinate usrng the Interne, cache protocol or 60 lateral access wilhin J ^ order tolervice non- 

ICP with an illustration of how a request directed into the „, , . „, . .. , . ,. . 

. . „ L enabled or legacy clients, but in turn may directly access the 

cache at one proxy server may query all other proxy servers „„ „„„,„ „.. „„ „<- , , , • ■] 

• .u 1 j I, . , , ' proxy server array of an Internet service provider, 
in the cache and eventually receive the data object laterally v 

from another proxy server in order to service the original DETAILED DESCRIPTION OF THE 

request. 6S PREFERRED EMBODIMENTS 

FIG. 4 is a block diagram of an exemplary system for As used herein, the term "hashing function" refers to 

implementing the present invention that includes a general those functions known in the art that systematically covert 
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one multi-bit representation into another, usually smaller, 
single or multi-bit representation. A hashing function is said 
to be deterministic if it generates the same results from the 
same input. 

As used herein, the term "data object" refers to any data s 
that may be accessed from a distributed store and singularly 
identified. Examples of data objects would include, but not 
be limited to, files, data base records, graphic images, 
programming "objects," etc. One particular data object that 
will used throughout the application is a URL data object m 
that is any resource that can be identified and accessed using 
a URL according to the HTTP protocol. Typically, this 
would be a Hyper Text Markup Language ("HTML") file 
that is located on a server of the World Wide Web and 
accessed using a URL. Those skilled in the art will appre- 15 
ciate that the invention as explained using URL data objects 
accessed over the Internet will apply to many other envi- 
ronments having a distributed store of data objects. 

As used herein, the term "array membership information" 
refers to information regarding all the servers making up an 20 
array of servers that can be configured into a distributed 
cache. As used more particularly throughout with one 
embodiment of the present invention, this would be infor- 
mation regarding proxy servers in a proxy server array that 
is used to cache URL data objects. Note that such array 25 
membership information may be incorporated into a file or 
data structure that may be shared or updated between the 
different array members, such as an array membership list. 
Array membership information would necessarily include 
some form of identification of each array member that can 30 
be used to access that member, such as server name or IP 
address. Additionally, array membership may include but 
not need not be limited to the following: a capacity for a 
particular server, a load factor that indicates a relative 
amount of load the server can handle as compared with other 35 
members of the array, and any information regarding server 
characteristics, such as CPU power, physical location, 
administrator's name, etc. 

Unless specified, a URL request may refer to an original 
request or a forwarded request. The term "generating" when 40 
referring to a URL request or other data object access s 
request could be an original request or a forwarded request 
received by a server and simply passed on to another server. 

As used herein, the term "distributed logical cache" or 
"distributed cache" refers to the cache as a whole over the 
entire proxy server array while "local cache" will refer to the 
data stored at a particular proxy server. 

As used herein, the term "URL" will be used to designate 
both a URL data object as well as a URL in the sense of the 50 
identifying title of the URL data object that indicates the 
location and object name that would be included in an HTTP 
request for a URL data object (also known as a URL 
request). An HTTP response would include the actual URL 
data object (also known as a URL response). 5J 

As commonly used throughout, a URL data object is 
always accessed from the proxy server cache, even if not 
there initially. Any request received that is not in the cache 
will be placed therein after the proxy server gets it from the 
destination server over the Internet. Therefore, a cache is 6o 
logically viewed for purposes of this application as contain- 
ing all possible URL data objects that may be desired and 
when speaking of requesting an object from the distributed 
cache, the object is presumed to be in the cache. 

It may be noted that the concepts of a proxy server acting 65 
as a store or cache for URL data objects may be applied to 
many different applications. For example, a distributed store 
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of data files over a network could be achieved by having a 
proxy server servicing clients directly with cached copies of 
ordinary files that are located elsewhere in a corporation's 
network server structure. Those skilled in the art will see the 
natural application of the concepts involving proxy servers 
for accessing Internet information to other information 
access scenarios. 

A "storage means," or "storage system" is defined broadly 
to incorporate any type of device interfacable with a CPU 
that is used to memorize information and includes both 
long-term and short-term storage. Thus, storage means 
would include, though not be limited to, cache memory, 
RAM, disk storage, tape storage, etc. Furthermore, storage 
means contemplates the entire system of storage incorpo- 
rated by a computer in combination so that the RAM, cache, 
and disk drive together could be considered a storage means 
or storage system. A storage means can also be logically 
partitioned into different locations so that items are stored in 
different media or on different parts of the same media. For 
example, a storage means comprising RAM and disk storage 
could be logically partitioned so that item A is stored in a 
portion of RAM (first partition or location), item B is stored 
in another portion of RAM (second partition or location), 
and item C is stored on disk (third partition or location). 

FIG. 4 and the following discussion are intended to 
provide a brief, general description of a suitable computing 
environment in which the invention may be implemented. 
Although not required, the invention will be described in the 
general context of computer-executable instructions, such as 
program modules, being executed by a personal computer. 
Generally, program modules include routines, programs, 
objects, components, data structures, etc. that perform par- 
ticular tasks or implement particular abstract data types. 
Moreover, those skilled in the art will appreciate that the 
invention may be practiced with other computer system 
configurations, including hand-held devices, multi- 
processor systems, microprocessor-based or programmable 
consumer electronics, network PCs, minicomputers, main- 
frame computers, and the like. The invention may also be 
practiced in distributed computing environments where 
tasks are performed by remote processing devices that are 
linked through a communications network. In a distributed 
computing environment, program modules may be located 
in both local and remote memory storage devices. 

With reference to FIG. 4, an exemplary system for imple- 
menting the invention includes a general purpose computing 
device in the form of a conventional personal computer 40, 
including a processing unit 41, a system memory 42, and a 
system bus 43 that couples various system components 
including the system memory to the processing unit 41. The 
system bus 43 may be any of several types of bus structures 
including a memory bus or memory controller, a peripheral 
bus, and a local bus using any of a variety of bus architec- 
tures. The system memory includes read only memory 
(ROM) 44 and random access memory (RAM) 45. A basic 
input/output system 46 (BIOS), containing the basic routines 
that helps to transfer information between elements within 
the personal computer 40, such as during start-up, is stored 
in ROM 44. The personal computer 40 further includes a 
hard disk drive 47 for reading from and writing to a hard 
disk, not shown, a magnetic disk drive 48 for reading from 
or writing to a removable magnetic disk 49, and an optical 
disk drive 50 for reading from or writing to removable 
optical disk 51 such as a CD ROM or other optica] media. 
The hard disk drive 47, magnetic disk drive 48, and optical 
disk drive 50 are connected to the system bus 43 by a hard 
disk drive interface 52, a magnetic disk drive-interface 53, 
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and an optical drive interface 54, respectively. The drives Based on the information in the array membership list 84 

and their associated computer-readable media provide non- and the HTTP request containing the URL for the URL data 

volatile storage of computer readable instructions, data object, the proxy server 86 will determine which proxy 

structures, program modules and other data for the personal server in the proxy server array 82 should contain the desired 
computer 40. Although the exemplary environment 5 URL data object. One way that this can be done, and which 

described herein employs a hard disk, a removable magnetic will be shown in more detail hereafter is by using a 

disk 49 and a removable optical disk 51, it should be deterministic hashing function to hash the URL received in 

appreciated by those skilled in the art that other types of the HTTP request 84 and combining it with a deterministic 

computer readable media which can store data that is hash of each server name in the array membership list 84 in 

accessible by a computer, such as magnetic cassettes, flash order to generate a rank ordering of each server in the array 

memory cards, digital video disks, Bernoulli cartridges, membership list 84 based on combined hash value 

random access memories (RAMs), read only memories Typically, the combining of the URL hash value and the 

(ROM), and the like, may also be used in the exemplary array membership list server hash values is itself another 

operating environment. deterministic hash. Furthermore, once the proxy servers 

A number of program modules may be stored on the hard found in the array membership list 84 are rank ordered the 
disk, magnetic disk 49, optical disk 51, ROM 44 or RAM 45, 15 proxy server with the highest combined hash value or score 

including an operating system 55, one or more application is chosen for locally caching the URL data object The 

programs 56, other program modules 57 and program data deterministic hashing algorithms used will calculate hash 

58 A user may enter commands and informal™ into the vaIues such that UR 6 L d * t> objec[s are even , distribu ^ 

personal computer 40 through input devices such as a „., ,u , ■ , tVBU1 J "^"'uuieu 

keyboard 60 and pointing device 62. Other input devTces 20 S,^^ ""^ m? array. Again, choosing 

(not shown) may include a microphone, joystickfgame pad, ^«^^t proxy server withm the proxy server array 82 that 

satellite dish, scanner, or the like. These and other input ^ f° ntain , the desired URL da,a ob J ect m ,he local cache 

devices are often connected to the processing unit 41 wU1 ^ ex P lained m greater detail hereafter, 

through a serial port interface 66 that is coupled to the Once the correct proxy server is determined, proxy server 
system bus, but may be connected by other interfaces, such 2 s 86 wi " direct a get 0D J ecl request to proxy server 90 as 

as a parallel port, game port or a universal serial bus (USB). shown by a get object message 92. Proxy server 90 will 

A monitor 67 or other type of display device is also respond by sending a copy of the URL data object back to 

connected to the system bus 43 via an interface, such as a proxy server 86 as indicated by the send object message 94. 

video adapter 68. In addition to the monitor, personal At this point, proxy server 86 may respond to the original 
computers typically include other peripheral output devices 30 HTTP request 84 thereby allowing the client 80 to have the 

(not shown), such as speakers and printers. requested URL data object. 

The personal computer 40 may operate in a networked It is important to note that regardless of which proxy 

environment using logical connections to one or more server in the proxy server array 82 receives the original URL 

remote computers, such as a remote computer 69. The request, for a particular URL, the same proxy server will be 

remote computer 69 may be another personal computer, a 35 indicated as having the URL data object in its local cache, 

server, a router, a network PC, a peer device or other This results from using deterministic hashing algorithms on 

common network node, and typically includes many or all of exactly the same information since every proxy server in the 

the elements described above relative to the personal com- proxy server array 82 will have an array membership list, 

puter 40, although only a memory storage device 70 has This is one way to determine the correct proxy server within 

been illustrated in FIG. 2. The logical connections depicted 40 a proxy server array that will have a desired URL object 

in FIG. 2 include a local area network (LAN) 71 and a wide without making queries between the proxy servers, 

area network (WAN) 72. Such networking environments are Only two messages are used to allow the proxy server 86 

commonplace in offices enterprise-wide computer networks, the ability to service the original URL request 84. Such a 

intranets and the Internet. proxy server array 82 does not exhibit the same negative 

When used in a LAN networking environment, the per- 45 scaleability problems associated with an ICP proxy server 

sonal computer 40 is connected to the local network 71 array since there is no need to have a query-response 

through a network or adapter 73. When used in a WAN transaction between the proxy server receiving the original 

networking environment, the personal computer 40 typically URL request and each and every other proxy server in the 

includes a modem 74 or other means for establishing com- array. In fact, there is a positive scaleability since as more 

munications over the wide area network 72, such as the 50 servers are added to the proxy server array 82, the greater the 

Internet. The modem 74, which may be internal or external, capacity for the distributed cache. 

is connected to the system bus 43 via the serial port interface An additional benefit of a proxy server array as shown in 

66. In a networked environment, program modules depicted FIG. 5 over an ICP array is that the capacity of the 

relative to the personal computer 40, or portions thereof, distributed cache is used more effectively with fewer dupli- 

may be stored in the remote memory storage device. It will 55 cate URL data objects stored at different local caches within 

be appreciated that the network connections shown are the entire distributed cache. This occurs since the determin- 

exemplary and other means of establishing a communica- istic hashing mechanism determines one designated proxy 

tions link between the computers may be used. server for each URL. 

Referring now to FIG. 5, a logical diagram showing a Referring now to FIG. 6, a flow chart showing the 

proxy server array according to the present invention that 60 processing steps taken by a proxy server found in the proxy 

allows lateral access of a URL data object without querying server array 82 as shown in FIG. 5 illustrates the processing 

all proxy servers in the array as would occur using ICP is steps taken upon receiving a URL data object request. After 

shown. A client 80 will access a proxy server array 82 beginning at step 100, a proxy server, such as proxy server 

configured to a distributed cache with an original HTTP 86 in the proxy server array 82 of FIG. 5, will receive a 

request 84 directed to proxy server 86. The proxy server 86 65 request for a particular URL data object at step 102. 

has an array membership list 84 that contains all the proxy An initial check is made to determine whether or not the 

servers that make up the proxy server array 82. URL is in the local cache at step 104. If the URL data object 
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is in the local cache, the response lo the originally received deterministically processed so that a proxy server that 

URL data object request will be serviced by returning the should have the URL data object contained therein as pan of 

URL from the local cache at step 106 before processing ends the local cache can be ascertained 
at step 108. Naturally taking the path of having the URL in Whi i c thos6 m , he m m de(ermin6 yarj 

Sues. l ° X ™* 3 URL 5 Wa ^ t0 deterministically arrive at a single proxy member 

' that can be consistently calculated regardless of which proxy 

As will be shown in greater detail hereafter, an "enabled" member is making the calculation, the discussion that fol- 
chent having the array membership information could do the lows presents one such way that works very effectively Note 
computations at the client for determining the correct proxy that the only real requirements for step 120 are that deter- 
server for a particular URL data object. Therefore, the 10 mu1 i s tic results are calculated when given the same starting 
original URL data object request can be made directly to the information, such as the URL name and the different servers 
proxy server most likely lo have the desired URL data that make up the proxy server array, and that queries need 
objecL not be sent out to all array members. While the present 

Should the URL data object of the received request not be embodiment has an array membership list that is available at 
located in local cache as determined at step 104, a check is 15 each proxy server that makes up the array, other embodi- 
made at step 110 to determine whether lateral access is ments may get or have the array membership information 
currently active for the proxy server array 82. If lateral differently than this embodiment yet still accomplish the 
access is not active, then the proxy server may operate as a purposes as explained. 

single proxy server rather than as in a distributed cache or Hashing algorithms can be used to deterministically cat- 
array member. Alternatively, if all clients to the proxy server 20 egorize both the array members and the URL itself The 
array are "enabled" clients, meaning that they have the present method comprises the following steps: (1) the array 
ability to directly access the designated proxy server for a membership list is analyzed and hash values are computed 
particular URL data object, then it can be assured that the on each of the proxy names found therein, (2) the URL name 
designated proxy server is the correct recipient of the URL that is used to access the URL data object is run through a 
data object request. 25 hashing algorithm and a hash value computed thereon, and 

At step 114, the proxy server would access the URL data (3) the two hashes are then combined taking into account a 
object over the Internet and receive a copy at the proxy l° aQ " factor that is assigned to each proxy server. The 
server, followed by placing the URL data object into the combined hash values will then give a numerical value for 
local cache at step 116, and finally returning the URL data 3Q each proxy server that is unique for the URL sought, such 
object to the client at step 118 as part of a response to the that the correct proxy server is chosen by taking the highest 
original URL data object request. Specific mention is made "score" or hash value with the corresponding proxy server 
at step 114 of accessing the URL data object over the being selected as the most likely proxy server to contain the 
Internet for simplicity sake since proxy server arrays may be URL data object in its local cache. 

clients to other proxy server arrays. Eventually, however, the 3J The hashing algorithm used is statistically designed so 
URL data object request will be finally resolved through the that URL data objects are assigned equally over N proxy 
Internet if no intervening proxy servers or proxy server servers in the proxy server array. When a proxy server hash 
arrays contain the object locally. Finally, processing would value is combined with a URL hash value, relative load 
end at step 108 until another URL data object request is factors can be taken into account so that proxy servers with 
received by the proxy server. ^ enhanced capacity will be assigned a proportionately greater 

If lateral access is active as determined at step 110, amount of the URL data objects, 
indicating that the proxy server is operating as part of a When changes are made to the proxy server array 
distributed cache in a proxy server array such as that shown membership, the URL data object assignments among the 
in FIG. 5, the request is analyzed to determine whether it array members may also change. A URL data assignment is 
was made from another member of the proxy server array or 45 where a particular URL data object would reside if requested 
an "enabled" client having access to the array membership from the proxy server array. In other words, every possible 
list and thus able to directly access the proxy server within URL data object will have an "assignment" to a particular 
a proxy server array thai is most likely to contain the desired proxy server in an array by operation of the deterministic 
URL data object in its local cache. If so, then the proxy hashing algorithm. 

server receiving the request is the correct proxy server but 50 The assignment changes are automatically manifest by the 
simply does not have the desired URL data object in the operation of the hashing algorithm since all the proxy server 
local cache as previously determined at step 104. In such a making up the array will be used as input Therefore if an 
case, the desired URL data object must be accessed over the addition or deletion occurs, the algorithm will function 
Internet at step 114 and placed in to the local cache at step differently, though still deterministically. For example if an 
116. At that point, the URL data object may be returned at 55 array is increased by one proxy server, each of the original 
step 118 to the client in an appropriate response before proxy servers will be assigned fewer of all possible URL 
processing ends at step 108. data ob j e cts to store in their local cache due to the addition 

If the request was not from another proxy server that was of the new proxy server. In like manner, if a proxy server is 
part of the same proxy server array or a client that had an removed from the array, each remaining proxy server will be 
array membership list and thus could make direct accesses 60 assigned additional potential URL data objects from among 
as determined at step 112, then the correct array member all possible data objects to store in their respective local 
proxy server must be determined at step 120. In other words, caches. 

at step 120, a deterministic way must be used to process The assignment changes for the universe of URL data 
available information in order lo avoid the detrimental objects implies that, besides changes in routing of newly 
query-response scenario carried out by ICR The array mem- 65 requested URL data objects, some actual URL data objects 
bership information as found in the array membership list in one proxy server cache will be moved or migrated to 
and the URL as found in the URL data object request are another proxy server as a result of an addition or removal of 
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a proxy server from the array. Due to an array membership 
change, the same request that would previously indicate one 
particular proxy server will now indicate another proxy 
server as having the desired URL data object in the respec- 
tive local cache. The URL data object would eventually be 
flushed from the first proxy server since no requests would 
be directed thereto due to the deterministic algorithm, while 
the new proxy server would receive the requests previously 
sent to the first proxy server. In this sense, the URL data 
object has "migrated" from one proxy server to another. 

When speaking of URL data object migration throughout 
this application, it entails both the change in assignment for 
a given hypothetical URL data object that may be requested 
from amongst al! possible URLdata objects as well as actual 
URL data objects that shift between different proxy server 
local caches over time. 

The deterministic algorithms used to make an "assign- 
ment" or route a URL data object request are designed so 
that only the minimum of URL data objects are switched 
between the proxy server in an array. For an array of N 
members, the addition of a proxy server will migrate 1/(N+ 
1) of the total URL data objects taken equally from the 
original N proxy servers to the newly added proxy server 
while the rest will remain unchanged. In like manner, the 
removal of a proxy server will cause the 1/N of the total 30 
URL data objects to migrate equally among the remaining 
N-l proxy servers. 

Below is a more detailed example of how the determina- 35 
tion is made at step 120. Initially, the names of all the proxy 
servers in the array are taken and hash values computed for 
each, followed by the computation of a hash value of ' 19' for 
URL #1, and finally, a combined hash value for each proxy 
server as shown below in Table 1. Note that, if the proxy 
servers are ordered from highest to lowest combined hash 
value and the selection criteria for the designated proxy 
server is choosing the highest "score" or combined hash 
value, the proxy server "SweetHeart" is identified or chosen 
to cache the data object associated with URL #1 in its local 
cache. 

TABLE 1 



14 



TABLE 2 



10 





URL m 


URL m 


URL #3 


URL #4 


Proxy Server Name 


Hash Value 


19 


14 


5 


2 


PearBlossom 


13 


5 


6 


;:f||§| 


4 


SweetHeart 


8 




2 


7 


5 


Honey 


5 


7 


4 


3 


S* 


Kitten 


28 


4 




8 


1 



The effect of adding an additional proxy server can be 
seen below in Table 3. A new proxy server named "Heidel- 
burg" has been added to the proxy server array with its own 
combined hash values for each URL. Since the combined 
hash value for the proxy server oamed "Heidelburg" and 
URL #2 is the highest score, the data object associated with 
URL #2 will migrate from the proxy server named "Honey" 
to the proxy server named "Heidelburg." 



TABLE 3 



25 





URL#1 


URL #2 


URL« 


URL #4 


Proxy Server Name 


Hash Value 


19 


14 


5 


2 


PearBlossom 


13 


5 


6 


U 


4 


SweetHeart 


8 




2 


7 


5 


Honey 


5 


7 


4 


3 




Kitten 


28 


4 


7 


8 


1 


Heidelburg 


14 


2 




4 


6 



40 





URL« 


Proxy Server Name 


Hash Value 


19 


PearBlossom 


13 


5 


SweetHeart 


8 


9 


Honey 


5 


7 


Kitten 


28 


4 



60 



Below, in Table 2, scores are generated for URL #2, URL 
#3, and URL #4. Note that the "winning" scores highlighted 
below for the all the URLs indicate a natural load balancing 45 
with one URL data object being stored or assigned to each 
of the respective proxy servers. 



While those skilled in the art will appreciate that many 
different ways may be devised to generate the hash values 
used in the previous tables as long as they are deterministic 
in nature. One form of deterministic hash algorithms used to 
create hash values for the proxy servers making up an array, 
the URL, and the combined hash values is explained below. 

Because irreversibility and strong cryptographic features 
are unnecessary for this application, a very simple and fasl 
hash function based on the bitwise left rotate operator is used 
on each textual character making up the URL. For each 
character in the URL or the proxy server name, one of the 
following respective functions is performed to arrive at the 
URL hash value: 

URL_Hash_Value+=_rotl(URL_Hash_Value, 19)+ 

<character_value> 
Proxy_Server Hash_Value+=rotl(Proxy_Server_ 

Hash_Value, 19)+<character_value> 
Additionally, the following steps are taken on the proxy 
server hash value in order to further spread the values across 
the hash space since proxy server names may be similar to 
each other: 

Proxy_Server_Hash_Value+=Proxy_Server_Hasb_ 
Value '0x62531965 

Proxy_Server_Hash_Value+=rotl(Proxy_Server_ 
Hash_Value, 21) 

The combined hash value is created by using the 
exclusive-OR function on the URL hash value and the proxy 
server hash value, multiplying by a constant, and performing 
a bitwise rotation according to the following formulas: 

Combined_Hash_Value=(URL_Hash_ValueOProxy_ 
Server_Hash_Value) 
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C °n m fi^^ aSb_ValUe+=COmbined - HaSh - ValUe * " the Same manner as ex P lained Previously in connection 

UxC>i53iyo5 for a \ 3len \ access within a proxy server array. This is 

Combined_Hash_Value=rotl(Combined_Hash_Value, accomplished by making the array membership list available 

I 1 * 10 me enabled cl «ent 136, and using the hashing algorithm 

While these particular hashing functions can be used, 5 that are used with the proxy servers within the array as 

those skilled in the art may develop many others that will explained previously in connection with step 120 of FIG 6 

work within the framework of ihe present invention. A load This provides even more efficient service to an enabled 

factor value associated with each proxy server may also be client since there are no messages traded between the proxy 

applied to each combined hash value io order to create a servers making up the proxy server array 140 By combining 

higher score for those proxy servers that have more capacity io the lateral access as shown in the logical diagram of FIG 5 

than others m a proxy server array. and lhe flow chart of FIG. 6, with the direcl access logical 

Once the proxy servers have been ordered by means of the model shown in FIG. 7 and explained in connection with the 

combined hash and a "winning" proxy server selected, the flow chart of FIG. 8, both enabled clients such as enabled 

URL data object request is forwarded to the highest non- client 136 of FIG. 7, and legacy or existing clients such as 

failed array member at step 122. A test is made at step 124 is client 80 of FIG. 5, can coexist in the same environment 

to determme whether forwarded request was successful, and This sort of arrangement will be explained in more detail 

if so, then the desired URL will be contained in the response hereafter in the discussion surrounding FIG 13 By com- 

to Ihe forwarded request. That URL data object can then be bining direct access by enabled clients and lateral access 

returned in response to the original URL data object request amongst array members, a proxy server array may provide 

made to the server at step 126. 2 o backwards compatibility while allowing greater flexibility 

Since this is a lateral access for the URL data object, it for more intelligent or enabled clients, 

will not be placed in the local cache. This is because it Referring now to FIG. 8, a flow chart showing the 

already exists in the local cache of the proxy server that was processing steps taken by an enabled client, such as enabled 

successfully accessed and to place it in this proxy server's client 136 of FIG. 7, in order to directly access lhe correct 

cache would create duplicate URL data objects in Ihe overall 25 proxy server containing the desired URL data object in a 

distributed cache, thereby decreasing overall cache efB- proxy server array is shown. After beginning at step 150 a 

ciency and capacity. At this point, processing would end at URL request is generated in some fashion as explained 

step 108 since Ihe original URL data object request had been previously. At step 152, the enabled client will determinis- 

serviced aca H y tj er ; ve tne most likely array member based on , he 

It the forwarded request was unsuccessful as determined 30 generated URL and the array membership list containing 

at slep 124, meaning that a timeout occurred and no response array membership information. One preferred way of doing 

was received, then the array membership list is updated at this has been explained previously in connection with a 

step 128 to indicate a particular proxy server has failed and proxy server in the discussion of step 120 of the flow chart 

is temporarily unavailable. This is likely to occur when a shown in FIG. 6. The same processing would occur in the 

proxy server is taken off line due to mechanical failure, 35 same preferred fashion for an enabled client and the details 

system maintenance, or other reason rendering it tempo- will not be repeated here. 

rarily unavailable to service HTTP requests. Once the most likely array member has been determined, 

At step 130, the next most likely array member is deter- the URL data object is requested from that array member at 

mined by taking the highest score of the proxy servers in the step 154. Should the array member return the desired URL 

array that have not been marked as temporarily unavailable 40 data object as determined at step 156, processing will end at 

(e.g. failed a request). Once the next proxy server is deter- step 158 since the client has received the desired URL data 

mined step 130, processing loops back to forwarding the object. 

request to that array member at step 122, and subsequent Should there be a timeout or other problem such that 

processing will be as explained previously. success was not achieved at step 156, the array membership 

Referring now to FIG. 7, an enabled client 136 will use its 45 list will be updated to temporarily mark the failed array 

own generated URL request in combination with the array member as unavailable at step 160. As explained previously 

membership list 138 in order to direct the original HTTP this may occur due to any reason the array member is 

URL data object request into the proxy server array 140 temporarily not available and it is expected eventually to 

directly to the proxy server 142 that is likely to have the return on-line. 

desired URL data object in its local cache. The URL 50 At step 162, the next most likely array member is deter- 

generated by the enabled client 136 may originate at the mined. Again, this is done by taking the proxy server having 

client m response to a user request or other stimulus or the highest combined hash value that has not been marked 

enabled client 136 may have received the URL data object as unavailable. Once the proxy server is determined at step 

request from elsewhere and may be simply forwarding such 162, processing loops around so that the enabled client may 

request. In any case, the term, "generated" refers to having 55 request the URL data object from the newly determined 

a URL data object request prepared so that it may be sent out array member at step 154. Again, processing will continue as 

to the proxy server array 140. Note that an enabled client . explained previously. 

may be a proxy server that is part of a proxy server array and Referring now to FIGS. 9A through 9D, a single proxy 

that the terms client and server are used to indicate relation- server array is shown that undergoes a number of different 

ships between computer systems. In other words, the same 60 changes due to the addition, removal, or temporary unavail- 

computer system may be a client or server depending on ability of a proxy server in the array. Initially, the proxy 

context - server array 166 exists as shown in FIG. 9A with a first 

By processing the information from the URL data object proxy server 168 having an array membership list 170 and 

request and the array membership lisl 138, the enabled client a second proxy server 172 having an array membership lisl 

136 is able to directly access the correct proxy server 142 65 174. The array membership lists 170 and 174 contain 

within the proxy server array 140. The determination of the relevant array membership information including a refer- 

correct proxy server, such as proxy server 142, can be done ence to each and every other proxy server found within the 
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array as shown in FIG. 9A. Note that such reference may be communicating the array membership lists between array 

by title, such as ASCII text location and name of the proxy members constitute only one way of providing and commu- 

server, by machine readable designation of the proxy server, nicating proxy server array membership information across 

such as an IP address, or any other means that allows a proxy the array and those skilled in the art will appreciate thai 

server to be uniquely identified. 5 many different ways and means may be implemented to 

In FIG. 9B, a third proxy server 176 with an array accomplish having valid array membership information 

membership list 178 has been added to the proxy server available at an enabled client or an array member so that a 

array 166 according to the steps shown in FIG. 11 as will be deterministic routing of a URL data object request may 

shown in more detail hereafter. Once the third proxy server occur based on that array membership information along 

176 has been added to the proxy server array 166, array 10 witb the . URL da ! a ob J ect rea , uest itself, 

membership information will be communicated between , Essentiall y. a time-to-live ("TTL") timer is implemented 

first proxy server 168, second proxy server 172, and third „ tn gS ers „ & e operation of the processing steps shown in 

proxy server 176 such that the corresponding array mem- fl ° W ch "l e " h - 1 ai ? enabled client or a me mber P^oxy 

bersbip lists reflect the addition of the third proxy server 176 TZV^J Pt ^J ^ & ■ S,6P 18 f °' lhe 7^ ,imer 

as will be explained later in connection with the steps shown 15 'uTrem ™ mJS^TJT™™ ° f ? ^ *° ' , £ 

in the flow chart of FIG. 10. current array membership list. An array member is randomly 

p»f»,r,„„ ,„ ci^ 00 ■. .• .u . selected from amongst the "active proxy servers found in 

Referring now to FIG. 9C, situation that occurs when a the m&y membership Ust ( J DQl ,. malked „ as 

proxy server is temporarily unavailable is shown. Namely, temporarily unavailable) to receive a request for that proxy 

the hrst proxy server 168 is shaded to indicate its temporary server's array membership list. 

unavailability due to maintenance, malfunction, or other 20 At step 186 a request for the array membership list of the 

such event. Furthermore, the array membership lists 174 and selected array member is made. Once a response is received 

178 of the respective second proxy server 172 and third containing the array membership list, the proxy server will 

proxy server 176 have the reference to the first proxy server update its own array membership list with information from 

168 "marked" in some fashion to indicate its unavailability. the newly received membership list. This may occur by 

The marking of a proxy server as temporarily unavailable 25 d^ct replacement or some form of differential analysis to 

occurs during routing of the URL data object request as part bring the proxy servers array membership lists up to date 

of a lateral access amongst proxy server in the array as based on the newly received information. Finally, the TTL 

explained in connection with the discussion of steps 124 and tiraer is resel 31 ste P 190 before processing ends at step 192 

128 of flow chart in FIG. 6 or as part of an enabled client's 10 aUow tne P rocess 10 re P e f 1 itse ' f periodically as needed, 

direct access into the array as explained in connection with 30 Tv Pically, having the TTL timer expire every second or so 

steps 156 and 160 of the flow chart shown in FIG. 8 As soon P rovides enough periodic resolution to effectively propagate 

as the first proxy server 168 again becomes available '™ y membershl F 'information in a timely manner, 

knowledge of its availability will be made known through- Jl^Tl ? *" ™ " «™P° raril .y ""available 

out the proxy server array 166 according to the loos! ly !^™TT,h * ^7 unmar , ked : or available 

ij . . s . luu!>cl y each cycle of the update process. In this manner whenever 

coupled array membership information propagation mecha- 35 a prev f ously unava |J a ble proxy server becomes available i 

msm explained in more detail hereafter in connection with wul be detectcd by an enabled client or a member of the 

the flow chart shown in FIG. 10. proxy ^ array . ^tiMy, when a proxy server is 

Referring now to FIG. 9D, the removal of the first proxy discovered to be temporarily unavailable, the enabled client 

server from the proxy server array is shown according to the or member of the array will not attempt any more accesses 

steps explained in more detail hereafter in connection with 40 to the unavailable proxy server for the duration of the TTL 

the flow chart shown in FIG. 12. Namely, the first proxy time period. All marking is temporary so that only complete 

server 168 is completely removed from the proxy server array membership lists are exchanged and a proxy server 

array 166 thereby leaving the second proxy server 172 and that continues to be unavailable will be discovered anew 

the third proxy server 176 as the only members left in the during the normal request processing, 

array. The data objects locally cached at the removed proxy 45 Referring now to FIG. 11, the steps taken in order to add 

server 168 will be redistributed or migrated equally (or a proxy server to the proxy server array are shown. Again, 

equally and according to load factor) with the remaining two many different implementations may be envisioned by those 

proxy servers. Again, the corresponding array membership skilled in the art that will allow a proxy server to be added 

lists 174 and 178 reflect the removal of the first proxy server to the proxy server array. 

50 After beginning at step 194, a new proxy server is 

Refernng now to FIG. 10, a flow chart showing the steps designated as being added to the array at step 196. In order 

taken for one method of communicating proxy server array to make this proxy server available to other members of the 

membership information between proxy servers and to array and enabled clients, the new proxy server is given 

enabled clients is shown. This is done by sharing array access or indication of at least one existing array member at 

membership lists between the proxy servers making up the 55 step 198 so that the new proxy server can request an array 

array on a periodic basis so that a change made to one array membership list from that existing proxy server at step 200. 

membership list will eventually propagate over to the other Upon receiving the request, the existing array member 

proxy servers in the array within a relatively short period of returns its array membership list and the new proxy server 

time. Such a "loose" propagation mechanism works well creates its own array membership list at step 202 using 

within the proxy server array environment even though 60 knowledge of the existing array member and the received 

those skilled in the art that other methods, such as broad- array membership list. Next, at step 203, the new proxy 

casting changes to all array members may provide more server notifies all members in its newly created array mem- 

immediate results. bersbip list of its existence in the proxy server array. Finally, 

The same general mechanism can be utilized by an at step 204, each existing member of the array member will 

enabled client to receive relevant changes in array member- 65 update its respective array memebership list in response to 

ship information. It is important to note that the use of array the notifications sent at step 203 before processing ends at 

membership lists and the presently explained method of step 206. 
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At this point, the newly added proxy server may now 
begin randomly accessing all members of the array for 
updating its own array membership list arid routing URL 
data object requests to the correct members of the array. As 
explained previously, FIG. 9B shows the state of the array 
previously shown in FIG. 9A after the addition of the third 
proxy server 176 at a point in time when the array mem- 
bership information has been propagated to all array mem- 
bership lists indicating the addition of the third proxy server 
176. 

Referring now to FIG. 12, flow chart showing the steps for 
removing a proxy server from a proxy server array is now 
shown. After beginning at step 208, a particular proxy server 
is designated as removed from the proxy server array at step 
210. 

At step 212, the designated proxy server notifies all proxy 
servers in its array membership list of its removal. The 
removed proxy server will no longer respond to requests 
directed thereto or may respond with some form of indica- 
tion that it is no longer a member of the proxy server array 
until its removal has propagated to all array members and 
enabled clients. Each proxy server remaining in the array 
will receive notification from the removed proxy server at 
step 212 and will update its respective array membershiplist 
to reflect the removal at step 214 so that no more attempts 
at accessing the removed proxy server for either the array 
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Assuming now that the enabled client 224 desires to 
access the exact same URL data object, it will use the 
generated URL data object request and the array member- 
ship list 234 in order to make the determination that the third 
proxy server 230 contains the desired URL data object. This 
occurs as was explained previously in connection with the 
logical diagram shown in FIG. 7 and steps 152 and 154 of 
the flow chart shown in FIG. 8. 

The third proxy server, upon receiving the URL request at 
step 102 of FIG. 6, will further determine that the desired 
URL data object is located in the local cache at step 104 and 
then directly service the URL request by returning the URL 
data object found in the local cache at step 106. Therefore, 
as shown in FIG. 13, both enabled clients such" as enabled 
client 224, and older clients, such as legacy client 222, 
utilize the same logical cache from the proxy server array 
220 that has the direct and lateral accessibility. 

Referring now to FIG. 14, a logical diagram is shown 
wherein there is two levels of proxy server array caching, 
one for an internal corporate proxy server array and a second 
for an Internet service provider proxy server array. In the 
scenario illustrated in FIG. 14, a corporate proxy server 
array 240 is an intelligent client to the Internet service 
provider proxy array 242 which in turn has access to the 
Internet 244 in order to connect with all servers on the World 



membership list or for routing of a URL data object request 25 Wide Web. A particular user pool 246 consisting of a group 



will be made. Finally, processing ends at step 216 

Referring now to FIG. 13, a logical diagram showing a 
proxy server array with lateral access between array mem- 
bers that will accommodate both legacy clients and enabled 
clients is presented. A legacy client 222 will access the proxy 
server array 220 in the traditional fashion by being assigned 
a specific proxy server while an enabled client 224 will 
utilize proxy server array member information in order to 
directly access the correct proxy server within the array 
having the desired URL data object as explained previously 
in connection with the logical diagram of FIG. 7 and the flow 
chart shown in FIG. 8. 

Assume the legacy client 222 directs a URL data object 
request to the first proxy server 226 of the proxy server array 
220 by way of assignment. The first proxy server 226 
determines that the desired URL data object does not reside 
in its local cache and uses the URL data object request and 
the proxy server array 220 membership information located 
in the array membership list 228 to ascertain that the desired 
URL data object should reside at the third proxy server 230. 
At that point, the request will be forwarded from the first 
proxy server 226 to the third proxy server 230 as indicated 
by the arrow. This determination and forwarding of the URL 
data object request received from the legacy client 222 at the 
first proxy server 226 is done according to step 120 and step 
122 of the flow chart of FIG. 6 as such processing steps are 
executed at the first proxy server 226. 

The third proxy server 230, upon receiving the forwarded 
URL data object request, will, for purposes of this example, 
determine that the URL is not in the local cache at step 104 
of FIG. 6, determine that lateral access is active at step 110, 
and that the request is from an array member at step 112. 
This basically indicates that the desired URL data object 
does not exist in the distributed cache and must be accessed 
over the Internet 232 and placed into the third proxy server 
230 local cache as was explained previously as step 114 and 
step 116 of FIG. 6. 

Finally, with the desired URL data object residing in its 
local cache, the third proxy server 230 may return the 
desired URL data object to the first proxy server 226, which 
in turn will service the original request from the legacy client 
222. Note that the first proxy server 226 will not store an 
extra copy of the URL data object in its local cache. 
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of legacy clients, such as legacy Internet browsers in a 
department or division, is assigned to direct requests to the 
first corporate proxy server 248 that is part of the corporate 
proxy server array 240. 

Each proxy server in the corporate proxy server array 240 
will have two array membership lists. The corporate array 
membership list will be used for managing lateral accessing 
in the corporate proxy server array 240 while the Internet 
service provider array membership list will be used by the 
corporate proxy server array 240 so that it may act as an 
intelligent client to the Internet service provider proxy server 
array 240. Furthermore, the Internet service provider array 
membership list will be used by the Internet service provider 
proxy server array 242 for managing lateral routing therein. 

Assuming a URL data object request from the user pool 
246 arriving at the first corporate proxy server 248, a 
determination is made at the first corporate proxy server 248 
using the receive URL data object request and the corporate 
array membership list 250 that the desired URL data object 
should reside on the second corporate proxy server 252. The 
first corporate proxy server 248 will forward the original 
URL data object request to the second corporate proxy 
server 252 as indicated by the arrow. 

Once the second corporate proxy server 252 determines 
that external access is required from the Internet or other 
upstream proxy server array, the Internet service provider 
array membership list 254 will be used in conjunction with 
the forwarded URL data object request information in order 
to determine exactly which proxy server in the Internet 
service provider proxy server array 242 will contain the 
desired URL data object in its local cache. Note that the 
second corporate proxy server 252 is acting as an enabled 
client in making this direct access into the Internet service 
provider proxy server array 242. 

The result of such determination by the second corporate 
proxy server 252 is another forwarded URL data object 
request from the second corporate proxy server 252 to the 
second Internet service provider proxy server 256 that will 
in rum bring the desired URL data object into its local cache 
after accessing it over the Internet 244. 

The response path will pass the desired URL data object 
from the second Internet service provider proxy server to the 
second corporate proxy server 252. The desired URL data 
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object will also be stored in local cache of the second 
corporate proxy server 252 so that there are now two cached 
copies, one in the corporate proxy server array 240 and one 
in the Internet service provider proxy server array 242. 

The second corporate proxy server 252 will respond to the 
first corporate proxy server array 248 with the desired URL 5 
data object. Upon receiving the response, the first corporate 
proxy server 248 will respond to the original URL data 
object request without storing the desired URL data object 
in its local cache to finalize the transaction chain. Those 
skilled in the art will recognize that may different topologies 10 
of proxy server arrays may be introduced that can be 
effectively serviced by the lateral and direct accessing 
methods disclosed herein. 

The present invention may be embodied in other specific 
forms without departing from its spirit or essential charac- 
teristics. The described embodiments are to be considered in 15 
all respects only as illustrated and not restrictive. The scope 
of the invention is, therefore, indicated by the appended 
claims rather than by the foregoing description. All changes 
which come within the meaning and range of equivalency of 
the claims are to be embraced within their scope. 20 

What is claimed and desired to be secured by United 
States Letters Patent is: 

1. In a client system associated with an array of servers 
configured so as to provide a distributed store of data 
objects, a method of transmitting a request for a data object 25 
to a single server of the array that is assigned to store the data 
object without sending queries to each server in the array to 
ascertain the location of the data object, the method com- 
prising the acts of: 
providing array membership information at the client 30 
system, the array membership information including 
information identifying each server that is active in the 
array at a given time; 
providing, at the client system, information identifying a 

data object that is to be accessed by the client system; 35 
determining which single server of the array is assigned to 
store the data object by performing the acts of: 
performing a first deterministic function on the infor- 
mation identifying the data object; 
for each server, performing a second deterministic 4Q 

function on the information identifying the server; 
combining the results of the first deterministic function 
with the results of the second deterministic function 
to generate a value for each server; and 
based on the relative values for the servers, determin- 
islically identifying which single server is assigned 
to store the data object, without sending a query to 
each server to ascertain the location of the data 
object; and 

transmitting an access request for the data object to the 50 
identified single server. 

2. The method of claim 1 wherein the data objects are 
Uniform Resource Locator ("URL") data objects, the serv- 
ers are proxy servers, the store of data objects is a cache of 
URL data objects, and the access request is a URL data 
object access request. ^ 55 

3. The method of claim 1 wherein the first deterministic 
function and the second deterministic function are determin- 
istic hash functions. 

4. The method of claim 3 wherein the act of determinis- 
tically identifying which single server is assigned to store 60 
the data object comprises the steps of: 

ordering the servers based on the values for the servers; 
and 

identifying the server having the highest value as being 
the server assigned to store the data object. 65 

5. The method of claim 1 wherein the array membership 
information is contained in an array membership list that is 
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distributed between the servers in the array and accessible to 
the client system. 

6. The method of claim 5 wherein the step of providing 
array membership information at the client system com- 
prises the acts of: 

periodically requesting a new array membership list from 
a randomly chosen server that is listed in a current array 
membership list stored at the client system; and 
updating the current array membership list with the new 
array membership list. 

7. A computer-readable medium having computer- 
executable instructions for performing the steps recited in 
claim 1. 

8. In a client system associated with an array of proxy 
servers configured so as to provide a cache of uniform 
resource locator ("URL") data objects distributed across the 
array of proxy servers, a method of transmitting a request for 
a URL data object to a single proxy server of the array that 
is assigned to store the URL data object, the method com- 
prising the acts of: 

providing an array membership list at the client system, 
the list including names of all proxy servers that is 
active in the array at a given time; 
providing, at the client system, a URL identifying a URL 
data object that is to be accessed by the client system; 
determining which single proxy server of the array is 
assigned to store the URL data object by performing the 
acts of: 

for each of the proxy servers that are active in the array, 
computing a first deterministic bash value of the 
name of the proxy server; 
computing a second deterministic hash value of the 
URL; 

combining, for each of the proxy servers active in the 
array, the first deterministic hash value and the 
second deterministic hash value to generate a deter- 
ministic combined hash value associated with each 
of the proxy servers active in the array; and 
based on the relative values of the deterministic com- 
bined hash values, deterministically identifying 
which single proxy server is assigned to store the 
URL data object; and 
transmitting a URL access request for the URL data object 
to the identified single proxy server. 

9. The method of claim 8 wherein the act of determinis- 
tically identifying which single proxy server is assigned to 
store the URL data object comprises the acts of: 

ordering the proxy servers based on the values for the 
servers; and 

identifying the proxy server having the highest determin- 
istic combined hash value as being the single proxy 
server assigned to store the data object. 

10. The method of claim 8 wherein each proxy server 
contains an array membership list and wherein the act of 
providing an array membership list at the client comprises 
the acts of: 

periodically requesting a new array membership list from 
a randomly chosen proxy server that is listed in a 
current array membership list stored at the client sys- 
tem; and 

updating the current array membership list with the new 
array membership list. 

11. A computer-readable medium having computer- 
executable instructions for performing the steps recited in 
claim 8. 

12. In a client system associated with an array of proxy 
servers configured so as to provide a cache of uniform 
resource locator ("URL") data objects distributed across the 
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array of proxy servers, a method of transmitting a request for 
a URL data object to a single proxy server of the array that 
is assigned to store the URL data object, the method com- 
prising the acts of: 

providing an array membership list at the client system, 5 
the list including information identifying all proxy 
servers that are active in the array at a given time, the 
list being located on each proxy server of the array, said 
act of providing an array membership list comprising 
the acts of: 10 
periodically requesting the array membership list 

located at a proxy server of the array; and 
updating the array membership list at the client system 
using the requested array membership list; 
in response to a URL request generated at the client 15 
system, determining which single proxy server is 
assigned to store a URL data object associated with the 
URL request without making a query to any of the 
proxy servers of the array, by performing the acts of: 
for each of the proxy servers that are active in the array, 
computing a first deterministic hash value based on 20 
the information identifying the proxy server; 
computing a second deterministic hash value of a URL 

associated with the URL request; 
combining, for each of the proxy servers active in the 
array, the first deterministic hash value and the 25 
second deterministic hash value to generate a deter- 
ministic combined hash value for each of the proxy 
servers; and 

based on the relative values of the deterministic com- 
bined hash values, deterministically identifying 30 
which single proxy server is assigned to store the 
URL data object; and 
forwarding the URL request to the identified single proxy 

server. 

13. A computer-readable medium having computer- 35 
executable instructions for performing the steps recited in 
claim 12. 

14. A computer-readable medium having computer- 
executable components for routing a uniform resource loca- 
tor ("URL") generated at a client system to a single proxy 4Q 
server that is assigned to store a URL data object associated 
with the URL request, the single proxy server being part an 
array of proxy servers configured so as to provide a distrib- 
uted cache of URL data objects, the components comprising: 

a request generating component for originating or for- 
warding a URL request that includes a URL associated 
with a URL data object that is to be accessed by the 
client system; 

a proxy server identification component for deterministi- 
cally identifying which single proxy server in the array 
is assigned to store the URL data object associated with 50 
the URL without sending queries to the all of the proxy 
servers in the array, including performing the acts of: 
for each of the proxy servers that are active in the array, 
computing a first deterministic hash value of a name 
of the proxy server; 55 
computing a second deterministic hash value of the 
URL; 

combining, for each of the proxy servers active in the 
array, the first deterministic hash value and the 
second deterministic hash value to generate a deter- 60 
ministic combined bash value associated with each 
of the proxy servers active in the array; and 

based on the relative values of the deterministic com- 
bined hash values, deterministically identifying 
which single proxy server is assigned to store the 
URL data object; and 



a routing component to route the generated URL request 
to the identified single proxy server. 

15. A system of server computers configured into a 
distributed cache for holding Uniform Resource Locator 
("URL") data objects and client computers that access the 
distributed cache, wherein a URL request generated at a 
client computer can be routed directly to the server computer 
that is assigned to store the requested URL data object 
without queries being made to any other server computer, 
the system comprising: 

at least two server computers, each server computer 
comprising: 
a CPU; 

storage means, electronically coupled and responsive to 
said CPU, said storage means containing member- 
ship information including information identifying 
all server computers included in the distributed 
cache; 

means, electronically coupled and responsive to said 
CPU, for receiving URL requests from clients of the 
distributed cache; and 
at least one client computer being a client of the distrib- 
uted cache, said client computer comprising: 
a CPU; 

storage means, electronically coupled and responsive to 
said CPU, said storage means containing member- 
ship information including information identifying 
all server computers included in the distributed 
cache; 

means, electronically coupled and responsive to said 

CPU, for generating a URL request; 
means, electronically coupled and responsive to said 

CPU, for deterministically identifying which single 

server computer in the distributed cache is assigned 

to store a URL data object associated with the URL 

request by performing the acts of: 

for each of the servers computers in the array, 
computing a first deterministic hash value of the 
information identifying the server computer; 

computing a second deterministic hash value of a 
URL that is associated with the URL request; 

combining, for each of the server computers, the first 
deterministic hash value and the second determin- 
istic hash value to generate a deterministic com- 
bined hash value associated with each of the 
server computers; and 

based on the relative values of the deterministic 
combined hash values, deterministically identify- 
ing which single server computer is assigned to 
store the URL data object; and 
means, electronically coupled and responsive to said 

CPU, for routing the URL request to the identified 

single server computer. 

16. A method as recited in claim 1, wherein the act of 
combining the results of the first deterministic function with 
the results of the second deterministic function to generate 
a value for each server comprises the act of using a third 
deterministic function selected so as to assign the data 
objects substantially evenly among the servers in the array. 

17. A method as recited in claim 1, wherein the act of 
combining the results of the first deterministic function with 
the results of the second deterministic function to generate 
a value for each server comprises the act of using a third 
deterministic function selected so as to assign the data 
objects with relative load factors among the servers in the 
array. 
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ABSTRACT 



In order to transparently redirect an HTTP connection 
request that is directed to an origin server (107) to a proxy 
cache (110-1), a proxy redireclor (104) translates the desti- 
nation address of packets directed to the origin server to the 
address of the proxy. During a handshaking procedure, a 
TCP connection is transparently established between the 
client (110-1) and the proxy cache. When the client transmits 
a GET request to what it thinks is the origin server, which 
request specifies the complete address of an object at thai 
origin server that it wants a copy of, the proxy redirector 
modifies the complete address specified in that GET request 
before it is sent to the proxy cache. Specifically, the IP 
address of the origin server found in the destination field in 
the IP header of the one or more packets from the client 
containing the GET request is added by the proxy redirector 
as a prefix to the complete URL in the GET request to form 
an absolute URL. The proxy cache determines from that 
absolute URL whether it has the requested object stored in 
its cache. If it does, it sends the object back to the proxy 
redirector, which masquerades those packets as coming from 
the origin server by translating their destination address to 
the address of the client and their source address to that of 
the origin server. If the proxy does not have the requested 
object, a separate TCP connection is established between the 
proxy and the origin server from where the object is 
retrieved and then forwarded over the TCP connection 
between the client and the proxy. In order to account for the 
additional number of bytes in the GET request, an acknowl- 
edgement sequence number in packets returned from the 
proxy that logically follow receipt of the GET request are 
decremented by that number by the proxy redirector before 
being forwarded to the client. Similarly, a sequence number 
in packets transmitted by the client subsequent to the GET 
request are incremented by that number before being for- 
warded by the proxy redirector to the proxy cache. 

55 Claims, 4 Drawing Sheets 
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METHOD AND APPARATUS FOR an IP address. First, a SYN packet is sent from the client to 

TRANSPARENTLY DIRECTING REQUESTS >hat origin server, wherein the destination IP address speci- 

FOR WEB OBJECTS TO PROXY CACHES fic d in the packet is the DNS-detennined IP address of the 

origin server and the destination port number for an HTTP 

FIELD OF THE INVENTION 5 request is conventionally port 80. The source IP address and 

. .. , , ... port number of the packet are the IP address and port number 

This invention relates to packet-switched computer associaled ^ lhe H c , iem ^ cliem , p „ 

networks, and more particularly, to a method and apparatus assigned l0 , he cljem by aQ , sp and , he cUem ^ * numb / f 

in such a network for transparently intercepting client web ^ dynamically assigned by the protocol stack in the client, 

requests and redirecting them to proxy caches. ^ The origin server then responds back to the client with an 

n«riTnnTiKm r,c tuc im^Kmrni ACK SYN packet in which the destination IP address and 

BACKGROUND OF THE INVENTION destination port are the client's IP address and port number 

Proxy caching is currently used to decrease both the and the packet's source IP address and port number are the 

latency of object retrieval and traffic on the Internet back- server's IP address and the server's port number, the latter 

bone. As is well known, if a proxy cache has stored a copy generally being port 80. After receipt of the ACK SYN 

of an object from an origin server that has been requested by 1S packet, the client sends one or more packets to the origin 

a client, the requested object is supplied to the client from server - whlcn packets include a GET request. The GET 

the proxy cache rather than from the origin server. This, rct * uest ™hdss a complete URL, which identifies to that 

therefore, obviates the need to send the request over a wide lhe ob J e * ™ th , in the ori ! in f ^ site that lhe 

area network, such as the Internet, to the origin server where „ ^t wants a copy of. Unlike an absolute URL, which 

• • , , . . • . , , .7 • . 20 includes both site information (e.g., www.yahoo.com), and 

the original object is stored and the response transmission object information ( iDde x.html), a complete URL only 

of a copy of the requested object back over the network to identifies lhe part > cu f ar objcc , (e / g _ ind / xMtm]) that £ 

the requesting client. requested since the packers) containing the GET request is 

Direction of a request from a client to a proxy cache to sent to the proper origin server site by means of the 

determine whether a requested copy of an object is stored in 25 destination address of the packet(s). 

the cache can be accomplished either transparently or non- When a browser is configured to non-transparently send 

transparently to the client. Non-transparent redirection is all requests to a proxy, a GET request is formulated by the 

accomplished through the client's browser program which is browser that includes the absolute URL of the requested 

configured to send all object requests to a designated proxy object. That absolute URL is then used by the proxy to 

cache at a specified address. Generally, a browser can be 30 establish a separate TCP connection to the origin server if 

configured to send all of its client requests to a designated the proxy does not have a copy of the requested object in its 

proxy cache if the client is connected on a Local Area cache. The proxy requires the absolute URL since the 

Network (LAN), or on an Intranet behind a firewall, where destination address of the packets to the proxy is set by the 

a proxy cache associated with that LAN or Intranet is browser to the IP address of the proxy rather than the IP 

located. When clients are served by a large Internet Service 35 address of the origin server. Thus, in order to determine 

Provider (ISP), however, it is not advantageous from the whether it has the object in its cache and if not establish a 

ISP's standpoint to allow its subscribers to set their browsers connection to the origin server, the proxy requires the 

to a specific proxy cache associated with the ISP. Alarge ISP absolute URL of the origin server in the GET request, 

likely will have many proxy caches in several locations and When requests are transparently directed to a proxy cache, 

will thus want to maintain control over which of its several 40 however, the client browser is unaware that the request is 

particular proxy caches a client request is directed. Further, being directed to the proxy and is possibly being fulfilled 

if a proxy cache whose address is statically set in a client's fjr 0m lrje cache. Rather, the client's browser needs to "think" 

browser becomes inoperative, all client requests will fail. tbat it is connected to the origin server to which its SYN and 

It is therefore more desirable from an ISP's standpoint the packet(s) containing the GET request are addressed, 

with respect to latency and minimizing traffic onto and off of 45 Such origin server IP address is determined by the browser 

the network to transparently intercept a client's web request through a. DNS look-up. Further, the source address of the 

and send it to one of its operative proxy caches to determine ACK SYN packet and the packets containing the requested 

whether a copy of the requested object is stored there. If a object must be that same origin server IP address or they will 

copy of the requested object is then found to be stored in that not be recognized by the browser as being the responsive 

proxy cache, a copy of the object is sent to the client, which 50 packets to the SYN packet and the request for the object, 

is unaware that it has been served an object from the proxy Thus, in order to transparently send object requests to a 

cache rather than from the origin server to which it made the proxy cache, a mechanism must be in place along the packet 

request. If the proxy cache does not hold a copy of the transmission path to intercept an initial SYN packet sent by 

requested object, then a separate connection is established a browser and to redirect it to the proxy cache to establish 

between the proxy cache and the origin server to obtain a 55 a TCP connection. The proxy cache must then masquerade 

copy of the object, which when returned to the proxy is sent as the origin server when sending the ACK SYN packet back 

to the client over the connection established between the to the client by using the origin server's IP address and port 

client and the proxy. number as the source address of that packet. Further, the 

When a client specifies a URLofthe object it is requesting subsequent packetfs) containing a GET request must be 

a copy of, a Domain Name Server (DNS) look-up is per- 60 redirected to the proxy cache and the request fulfilled either 

formed to determine from the URL an IP address of an origin from the cache or via a separate TCP connection from the 

server which has that requested object. As a result of that proxy to the origin server. In either case, the source address 

look-up, an IP address is returned to the client of one of what of packets sent back to the client must be the origin server's 

may be several substantially equivalent servers that contain IP address and port number to which the packets sent by the 

that object. The client then establishes a TCP connection to 65 client are addressed. 

that server using a three-way handshake mechanism. Such a In order for packets associated with a request for an object 

connection is determined at each end by a port number and to be redirected to a proxy cache connected somewhere in 
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the network, a Layer 4 (L4) switch on the packet path 
"looks" at the port number of a destination address of a SYN 
request packet. Since HTTP connection requests are gener- 
ally directed to port 80 of an origin server, the L4 switch 
transparently redirects all packets having a port number of 5 
80 in the destination address. The SYN packet is thus sent 
to a selected proxy cache. In order for the proxy cache to 
properly respond to the client, as noted, it must know the 
absolute URL of the requested object and packets returned 
to the client must masquerade as coming from the origin 10 
server. Unlike the non-transparent caching method previ- 
ously described in which the browser formulates a GET 
request with the absolute URL, for transparent caching the 
absolute URL must be provided in some manner to the proxy 
cache in order for the proxy to determine whether it in fact is 
has the requested object in its cache, or whether it must 
establish a separate TCP connection to the origin server to 
request the object. In the prior art, when one or more caches 
are directly connected to the L4 switch, the switch chooses 
one of the caches and transparently forwards the packets to 
that proxy without modifying the source or destination 
address of the packets. The proxy, working in a promiscuous 
TCP mode accepts all incoming packets regardless of their 
destination address. The proxy, then receiving the SYN 
packet with the origin server's destination address and the 
client's source address, can respond to SYN packet with an 
ACK SYN packet. This ACK SYN packet has the client's 
address as a destination address and a source address mas- 
querading as the origin server address. This packet is trans- 
ported through the L4 switch onto the network over the TCP 
connection back to the client. The subsequent packet(s) with 
the GET request from the client is redirected by the L4 
switch to the directly connected proxy. Since the GET 
packet(s) only contains the complete URL, the proxy must 
formulate the absolute URL to determine whether its has the 
requested object in its cache or whether is must establish a 
separate TCP connection to the origin server. The proxy 
forms the absolute URL by prefixing the complete URL in 
the GET request with the IP address of the origin server in 
the destination address of the packet. The proxy can then 
determine whether it has the object and, if not, establish a 
TCP connection to that absolute address. If that particular 
origin server at that IP address should be inoperative, the 
proxy can alternatively prefix the complete URL in the GET 
request with the logical name of the site indicated in the 
HOST field in the packers) containing the GET request. 

In the prior art, if the proxy cache is not directly connected 
to the L4 switch, then the L4 switch must perform a network 
address translation (NAT) and port address translation (PAT) 
on those packets directed to port 80 of an origin server. 
Specifically, when the L4 switch receives a SYN packet to 
initiate a TCP connection from a client to an origin server, 
it translates the destination address of the packet from the IP 
address and port number of the origin server to the IP 
address and port number of a selected proxy cache. Further, 
the switch translates the source address of the packet from 
the clients IP address and port number to its own IP address 
and a port number. When the proxy responds with an ACK 
SYN packet, it therefore responds to the L4 switch where a 
NAT translates the destination IP address from the IP address 
of the L4 switch to the IP address of the client, and translates 
the source IP address from the IP address of the proxy to IP 
address of the origin server. A PAT also translates the port 
number in the destination address from that of the L4 switch 
to that of the client, and translates the port number in the 
source address from that of the proxy to that of the origin 
server (usually 80). When the client sends an ACK packet 
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and then the packet(s) containing the GET request to the 
origin server, the L4 switch again performs a NAT, trans- 
lating the destination IP address to the IP address of the 
proxy. Thus, when the packers) containing the GET request 
is received by the proxy, it does not know the IP address of 
the origin server as in the directly connected proxy arrange- 
ment described above. The proxy must therefore look at the 
logical name in the HOST field and perform a DNS look-up 
to determine that site's IP address. The proxy then uses that 
IP address in combination with the complete URL in the 
GET request to form an absolute URL from which it 
determines whether it has the requested object in its cache. 
If it doesn't, a separate TCP connection is established from 
the proxy to that absolute URL to retrieve that object, which 
is returned to the proxy. Whether the object is found in the 
proxy cache or is retrieved over the separate connection 
from the origin server, it is forwarded back to the L4 switch 
where a NAT and PAT are performed to translate the 
destination address to that of the client and to translate the 
20 source address to the particular origin server to which the 
client's request was directed. It should be noted that the 
source address of the origin server obtained when the 
client's browser initiates a DNS look-up using the origin 
server's absolute URL may not be the same IP address 
2s obtained when the proxy performs a DNS look-up using the 
combination of the site URL in the HOST field and the 
complete URL in the GET request. 

The above described techniques for performing transpar- 
ent proxy caching have several disadvantages. Firstly, use of 
30 a HOST field to specify a logical name of an origin server 
is not currently incorporated within the presently employed 
HTTP1.0 standards. Thus, a HOST field may not be present 
in the packers) containing a GET request. Where, as 
described above, the information in the HOST field is 
35 necessary to form an absolute URL to determine whether the 
proxy cache has the requested object and, if not, to establish 
a connection to an origin server from the proxy, the absence 
of the HOST field results in an unfilled request. Secondly, 
the prior art techniques require the proxy cache to perform 
40 the function of forming an absolute URL from the informa- 
tion in the HOST field and in the packet(s) containing the 
GET request. Thus, standard proxy caches which expect the 
client's browser to produce the absolute URL cannot be 
used. A methodology for transparent proxy caching that is 
45 transparent to both the client and the proxy is desirable to 
avoid modification to the program that controls proxy cache 
operations. Standard proxy caches could thus be employed 
anywhere in the network without the need for a special 
implementation, 
so The above described prior art techniques have even 
further disadvantages with respect to persistent connections 
defined by the HTTP1.1 standards. As defined by these 
standards, a persistent connection enables a client to send 
plural GET requests over the same TCP connection once that 
55 connection has been established between two endpoints. 
When a prior art transparent proxy cache is interposed on the 
connection, a client may "think" it has established a persis- 
tent connection to the specific origin server determined 
through the DNS look-up. The connection in reality, 
60 however, is transparently diverted by the L4 switch to a 
proxy cache. The proxy cache, in response to a DNS look-up 
using the logical name in the HOST field, may be directed 
to an equivalent origin server at a different IP address. 
Further, as each subsequent GET request is received by the 
65 proxy from the client within the client's perceived persistent 
connection, each responsive DNS look-up to the logical 
name may direct a connection to an even different IP address 
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of an equivalent origin server. As a result, the advantages of 
a transaction-oriented persistent connection in which a 
server is capable of maintaining stale information through- 
out the connection, are lost. A methodology is desirable that 
maintains persistence to the same origin server to which the s 
clients browser is directed, or to a same equivalent origin 
server throughout the duration of the persistent connection. 

SUMMARY OF THE INVENTION 

The problems associated with the prior art techniques for 10 
transparent proxy caching are eliminated by the present 
invention. In accordance with the present invention, a 
switching entity, such as the L4 switch (referred to herein- 
after as a proxy rediiector), through which the packets flow, 
is provided with the functionalities at the IP level necessary 15 
to transform the complete URL in each GET request trans- 
mitted by a client to an appropriate absolute URL. 
Specifically, the IP address found in the destination field in 
the IP header of the packet(s) from the client containing the 
GET request are added as a prefix by the proxy redirector to 20 
the complete URL in the GET request. As a result, the 
complete URL in the GET request is modified to form an 
absolute URL which, when received by the proxy cache, is 
directly used to determine if the requested object is stored in 
the cache and, if not, to establish a separate TCP connection 25 
to the origin server. The GET request received by the proxy 
is thus equivalent to what it would expect to receive if it 
were operating in the non-transparent mode. 
Advantageously, if a persistent connection is established, 
each subsequent GET request has the same IP address prefix 30 
determined by the initial DNS look-up by the client. 

By modifying the GET request at the proxy redirector to 
include the destination address of the origin server, the 
number of bytes at the IP level in the packet containing the 
resultant absolute address are increased by the number of 35 
bytes in the prefix. Included in the header within each packet 
is a sequence number (seq) that provides an indication of the 
position of the first byte number in the payload. Thus, when 
the IP address is added to a packet, the sequence number of 
each of the subsequent packets needs to be incremented by 40 
the count of the added bytes. Further, an acknowledgement 
sequence number (ack_seq) in the header on the packets 
returned from the proxy or the origin server that logically 
follow receipt of the GET packet(s) at the origin server 
needs to be decremented by the proxy redirector before 45 
being forwarded to the client to avoid confusing the client 
with respect to what the sequence number of the next byte 
it sends should be. Further, if the GET request sent by the 
client encompasses more than one TCP segment, then the 
extra bytes in the first of the segments caused by the 50 
additional bytes added to the URL are shifted into the second 
segment, and the resultant now extra bytes in the second 
segment are shifted into the third segment, etc., until the last 
of the segments. In order to preclude the necessity of 
requiring an extra segment to be added to the GET request 55 
to accommodate the extra bytes, the client sending the GET 
request, is deceived into sending segments whose maximum 
size is less than what can actually be received by the proxy 
as indicated by a maximum segment size (MSS) field in 
packets from the proxy. The proxy redirector, upon receipt 60 
of the On, ACK SYN packet from the proxy, reduces the 
MSS parameter received from the proxy by the amount of 
the number of bytes that will be added to the GET request 
before that parameter is forwarded to the client. Thus, when 
the client next sends a GET request, each segment is limited 65 
to the reduced MSS, thereby insuring that the segment size 
of a last segment in a GET request after the IP address is 
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prefixed by the proxy redirector to form the absolute URL 
(whether the GET request is one or more segments long) is 
less than or equal to the actual MSS that the proxy can 
receive. 

BRIEF DESCRIPTION OF THE DRAWING 

FIG. 1 is a block diagram of a network that includes a 
proxy redirector that transparently sends requests from a 
client to a proxy cache by changing the destination address 
of packets in a client request from that of the origin server 
to that of a proxy and the source address from that of the 
client to that of the switching entity and, in accordance with 
the present invention, modifies a GET request to include the 
destination address of the origin server; 

FIG. 2 is a block diagram showing the proxy redirector 
implemented on a programmable network element that 
manipulates packets in accordance with instructions pro- 
vided by a loaded program; and 

FIGS. 3, 4, 5 and 6 are flow charts detailing the operation 
of the proxy redirector. 

DETAILED DESCRIPTION 

With reference to FIG. 1, a plurality of clients 101- 
1-101-N are connected to a local area network (LAN) 102, 
such as an Ethernet. LAN 102, which, in turn, is connected 
through a router 103 to a Level 4 (L4) switch 104 (proxy 
redirector) which interfaces the LAN with a wide area 
network (WAN) 105, such as the Internet. Although shown 
as two separate elements, the functionalities of router 103 
and proxy redirector 104 can in actual practice be combined 
in a single unit. All requests from any of the clients con- 
nected to LAN 102 for objects stored in servers connected 
to the Internet 105 traverse proxy redirector 104 onto the 
Internet. The packets comprising such requests, which 
include the standardized packets that establish a TCP 
connection, are directed to an IP destination address and port 
number indicated in the IP header of each packet originating 
from a client source address that includes a client IP address 
and port number. Similarly, responses to such requests from 
an origin server connected to Internet 105 are directed via an 
IP destination address that is equal to the client's IP address 
and port number from which the request originated, and 
have as a source address the server's IP address and port 
number. All such packets directed to any of the clients 
101-1-101 -N from any server connected to Internet 105 pass 
through proxy redirector 104. 

When any of the clients connected to LAN 102, such as 
client 101-1, makes a request through a browser for an 
object by specifying a logical URL, a domain name server 
(DNS) 106 connected locally or on Internet 105, as shown, 
is accessed to perform a database look-up based on that 
logical name. An associated IP address is then returned to the 
browser. The IP address returned to the browser is the IP 
address of a particular origin server which contains the 5 
object requested through the logical URL. Since a logical 
name may in fact be associated with a plurality of essentially 
equivalent origin servers, such as servers 107 and 109, the 
particular IP address returned to the client browser chosen 
by DNS 106 may be determined in a round-robin manner. 
When DNS 106 selects an origin server corresponding to the 
logical URL, the IP address of the selected origin server, 
such as, for example, the IP address of origin server 107, is 
returned to the browser in the requesting client 101-1. That 
IP address then serves as the IP address to which packets 
directed to the origin server from the client are directed. 
Conventionally, hltp requests are usually directed to port 80 
of an origin server. 
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With the IP address of the origin server determined and have been manipulated in accordance with the gateway 

returned to the client, the browser establishes a TCP con- program back to the kernel for output back to the network 

nection between the client and the origin server through a through filter 203 through network interfaces 208. Library 

three-way handshaking process. Specifically, a SYN packet, functions are provided in the programmable network ele- 
addressed to the IP address of the selected origin server, is 5 ment that enable a gateway program to communicate with 

sent by the client. Handshaking is completed when the client the dispatcher process 202 to register rules that specify the 

receives an acknowledgement of receipt of that SYN packet type of IP packets that a gateway program wants diverted to 

through an ACK SYN packet sent by that origin server, and it. A gateway program can request either a complete IP 

responds with a ACK packet to the origin server. The packet or only the IP and TCP header of a packet and can 

browser then sends a GET request that specifies the partial- 10 change both the header and payload of a packet, 

lar requested object. I D the present invention, that programmable network 

In accordance with the present invention, once the IP element is operative in combination with a gateway program 

address of the origin server corresponding to the logical that manipulates the destination and source addresses of 

URL name is determined through the DNS look-up, proxy packets flowing there through in a manner to be described, 

redirector 104, rather than establishing a TCP connection to 15 as well as modifying, as will be described, information in the 

the origin server at the determined IP address, transparently packet(s) containing the GET request that specifies the URL 

establishes a TCP connection between the client and a proxy. of the requested object. Specifically, the programmable 

If the requested object is stored in the cache, a copy of that network element in combination with the gateway program 

object is transparently returned to the requesting client. A operates on packets associated with HTTP requests, which 

TCP connection, therefore, is not established over the Inter- 2 o are determined from the destination port number. As previ- 

net 105, to the actual origin server 107 to provide the ously noted, HTTP requests are conventionally addressed to 

requested object to the requesting client. The coss of trans- port 80 of an origin server. Thus, the programmable network 

mining the request to the origin server over the Internet and element/gateway program which together comprise proxy 

transmitting the copy of the requested object back over the redirector 104 in this embodiment, captures through the 

Internet are thereby saved in addition to the time required for 2 s dispatcher process of the programmable network element, 

transmitting such a request over the Internet and waiting for packets directed to port 80 and then performs address 

a response from the origin server. If the proxy cache to translations on those captured packets to readdress these 

which the request is directed does not contain the requested packets to a selected proxy. With respect to address 

object, a separate TCP connection is established between the translations, the gateway program translates the destination 

proxy cache and the origin server to obtain a copy of the 30 IP address of packets addressed to the origin server to the IP 

requested object. When the proxy cache then receives the address of a selected proxy cache and translates the source 

copy of the requested object from an origin server over that IP address of such packets from that of the client to the IP 

separate TCP connection, the copy is forwarded to the client address of proxy redirector 104. Further, in order for proxy 

over the original TCP connection that was established redirector 104 to identify requests from plural client termi- 

between the client and the proxy cache. 35 nals that are directed to the same proxy, the source port 

In the embodiment shown in FIG. 1, a proxy cache 110-1 number is translated to a bogus ghost port number at the 

is illustratively shown connected to a LAN 111, which is proxy redirector. Thus, when proxy cache responds, the 

connected to LAN 102 through a router 112. Another proxy packets transmitted by the cache have a destination IP 

cache 115 is shown connected on a different LAN 116 address of proxy redirector 104 at that bogus port number, 

through router 103. Other proxy caches can be located 40 which is distinctly associated with the client. The gateway 

anywhere on LANs 102, 111, or 116, on another LAN program within proxy redirector 104 then translates the IP 

connected to the Internet 105 such as proxy cache 117. destination address of these responsive packets from the 

Proxy redirector 104 selects one of the available proxy proxy to the IP address of the client and translates the bogus 

caches to which to forward client requests based on a metric destination port number to the port number from which the 

such as least-loaded or round-robin, based on IP header 45 client originated its request. Further, the gateway program 

information such as the origin server IP address. With translates the source IP address of such responsive packets 

respect to the latter, all objects from a specific origin server from that of the proxy to the IP address of the origin server 

will be served by a specific proxy. and the port number to the port (80) to which the client's 

In the preferred embodiment described herein, proxy requests were originally directed. Thus, the packets which 

redirector 104 includes a programmable network element of so arc returned to the client from the proxy masquerade as if 

the type described in co-pending U.S. patent application Ser. me y na d originated from the origin server to which the client 

No. 09/190,355, filed Nov. 12, 1998, which application is "believed" its request had been sent, 

incorporated herein by reference. As described in that By performing the above-described network address 

application, that programmable network element in the translations (NATs) and port address translations (PATs), 

preferred embodiment runs on a Linux machine. As shown 55 packets from a client 101-1 are transparently directed by 

in FIG. 2, the programmable network element 200 includes proxy redirector 104 to a proxy cache. Responsive packets 

a dispatcher process 202 with which plural different gateway from the proxy cache are sent to proxy redirector 104 where 

programs (204, 205 and 206) register and request access to they are redirected to client 101-1. 

IP packets that fit specific descriptions. Such programs are In establishing a TCP connection that is directed to an 

loaded through an admission daemon 210 via a local pro- 60 origin server, client 101-1 first transmits a SYN packet, 

gram injector 211 or a remote program injector 212. A which is intercepted by proxy redirector 104. Proxy redi- 

gateway program, for example, can request access to incom- rector 104 selects a proxy cache, such as proxy 110-1, to 

ing packets to network interface 208 that match certain redirect this request and creates a connection control block 

source and destination IP address ranges and port numbers. (CCB) to maintain information about the connection. Selec- 

The dispatcher process 202 uses a packet filter 203 in the 65 tion of the particular proxy is determined, as described 

Linux kernel 201 to obtain packets requested by the gateway above, by one of several possible algorithms. The CCB is 

programs and uses a raw IP socket 215 to send packets that used to store the client IP address and TCP port number and 
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ihe origio server IP address and TCP port number, both of 
which are contained in the IP header of the SYN packet, and 
the chosen proxy's IP address. The destination address is 
then changed to that of the chosen proxy and the packet is 
sent back to the network for redirection to its new destina- 5 
lion address of ihe proxy 110-1. All subsequent packets thai 
originate from the same client with the same TCP port 
number are then forwarded to the same proxy. Proxy 110-1 
responds with an ACK SYN packet which is directed via its 
destination address to proxy redirector 110-1. Proxy redi- to 
rector 104 then translates the source IP address and port 
number to those of the origin server and the destination IP 
address and port number to those of the client. When the 
packet arrives at the client the client believes that it is 
connected to the origin server. The client then responds with 15 
an ACK packet to the origin server, which is redirected by 
proxy redirector 104 to proxy cache 110-1, to complete the 
handshaking process. 

After Ihe TCP connection is established between client 
101-1 and proxy cache 110-1, client 101-1 sends one or 2u 
more packets containing a GET request addressed to the 
origin server. Such packets are thus "captured" by proxy 
redirector 104 and redirected to proxy cache 110-1. As 
previously discussed, the GET request sent by the client 
contains only the complete URL sent by the client browser 25 
which in itself provides insufficient information for the 
proxy cache to determine whether it has the requested object 
and, if not, to forward it to the origin serve.r which does. In 
accordance with the present invention, the gateway program 
that is operative with the programmable network element of 30 
the proxy redirector 104, captures this packet or packets and, 
in addition to previously described address translations, 
transforms the complete URL to an absolute URL by pre- 
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fixing il with the IP address of the origin server obtained 
from the destination IP address of the packers) containing 
the GET request. Thus, Level 7 (application) information is 
modified to assist in level 4 routing. 

In order to make the URL transformation transparent to 
both the client and proxy cache endpoints, changes in IP and 
TCP headers are also required. Since the GET request 
modification increases the length of the IP packet that carries 
the GET request, the total length field on the IP header of this 
packet is increased by an offset. The offset amount is 
recorded in the CCB. In addition, the TCP header contains 
sequence numbers (seq) and acknowledgement sequence 
numbers (ack_seq) that need to be translated. The seq in the 
TCP header indicates the byte number of the first by te on this 
packet going from the sender to the receiver over the TCP 
session and the ack_seq indicates the byte number of the 
next byte that the sender expects to receive from the 
receiver. For all packets after the GETpacket(s) that go from 
the client to the proxy cache, the seq is increased by an offset 
equal to the lengthof(absolute URL)-lengthof(complete 
URL) so that the seq matches the byte number of the byte 
that the proxy cache expects to receive from the client. 
Similarly, on all packets starting with the acknowledgement 
to the GET packet that go from the proxy cache to the client 
through the proxy redirector, the ack_seq is decreased by 
the same offset so that the ack_seq matches the byte number 
of the byte that the proxy cache would expect the client to 
send in the next packet following the GET packet. By 
performing these changes in the header, the client and proxy 
cache endpoints remain unaware of the modification in the 
GET packets from the complete URL to the absolute URL. 

Table 1 illustrates the URL and other header transforma- 
tions performed 



TABLE 1 

Arriving packet: 

— > beginning of packet header dump < — 

— > IP header: version=4 hdr_len-5 TOS-0 pkt_len=346 id=60276 

frag_off=4000H TTL-64 prolocol=6 cksurn-1 792H 

saddr-135. 104.25.243 daddr-204.71 .200.244 
— > TCP header sport=1273 dport=S0 seq=2189084427 ack_seq=3266449517 

tcp_hdr_len=5 fiags=ACK PSH 

resl-OH res2-0H window=31856 cksum-162H urgent-0 
— > beginning of packet data dump <--- 
GET /a/ya/yahoomail/promol.gif HTTP/1 .0 
Rcfcrcr: http://www.yahoo.com/ 
Connection: Keep-Alive 

User-Agent: Mozilla/4.05 [en] (XI 1; U; Linux 2.1.103 i686) 
Host: us.yimg.com 

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg image/png 
Accept-Language: en 
Accept-Charset: isc-8859-1, ",utf 8 
Modified to: 



— > beginning of packet header dump < — 

— > IP header: version=4 hdr_len=5 TOS=0 pkt_Ien=367 id=60276 

frag_off-4000H TTL-64 protocol-6 cksum-]792H 

saddr=135.104.2S.245 daddr-135.10«.25.31 
— > TCP header spon»5000 dport-7000 scq-2189084427 ack_seq»3266449517 

tcp_hdr_!en-5 fiags-ACK PSH 

resl-OH res2-0H window-31856 cksum-162H urgent-0 
— > beginning of packet data dump <— 
GET http^/204.71.200.244/a/)'a/yahoomail/proniol.gif HTTP/1.0 
Referer: http://www.yahoo.com/ 
Connection: Keep-Alive 

User-Agent: Mozilla/4.05 [en] (X13; U; Linm 2.1.103 i68<S) 
Host: us.yimgxom 
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Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg image/png 
Accept-Language: cn 
Acccpt-Charscl: iso-8859-1, ",ulf 8 



on a GET packet that arrives at proxy redirector 104 from a 
client 101-1. The packet is destined to an origin server at a 
destination IP address (daddr) 204.71.200.244 
(www.yahoo.com) at a destination port (dport) 80, request- 
ing object /a/ya/yahoomail/promol.gif. As can be noted in 
the modified packet, the packet is redirected to a proxy cache 
110-1 at IP address 135.104.25.31 port 7000 by changing the 
daddr and dport header information. Also, the complete URL 
of the object in the GET request is modified in the translated 
packet by prefixing it with http://204.71.200.244 to form the 
absolute URL, where that prefix is obtained from the daddr 
header in the arriving packet. This transformation increases 
the length of the packet by 21 bytes so that the pkt_len field 
in the header is modified from 346 to 367 bytes. Further, the 
source port is modified to a bogus port number by changing 
sport to 5000. 

Table 2 shows the translations performed by the proxy 
redirector 104 to an acknowledgment from proxy cache 
110-1 to the GET request. The arriving 



length of the GET packet by 21 bytes, proxy redirector 104 
decreases the ack_seq field by the number of bytes added, 
21. Further, proxy redirector 104 translates the destination IP 
address and port number to those of the client 101-1, and the 
source IP address and port number to that of the origin 
server. The modified packet, when received by the client, 
thus appears to the client to have originated from the origin 
server and the ack_^seq field indicates a byte number that the 
client would next expect to send having previously sent a 
packet of length 367 bytes. All packets that are subsequently 
sent through the proxy redirector 104 to client 101-1 from 
proxy cache 110-1 are similarly modified to decrement the 
ack_seq field by the number of bytes, 21, added to the GET 
packet. 

Table 3 illustrates a next packet sent by client 101-1 to the 
origin server after the GET packet. In this packet the 
sequence number (seq) is equal to the modified ack_seq 
sent to the client, as per Table 2. The destination IP address 
and port number are those of the origin server and the source 



TABLE 2 



Arriving packet: 

— > beginning of packet header dump <— 

— > IP header: version-4 hdr_len-5 TOS-0 pkt_len-40 id-]4559 

£rag_off=4000H TTI^255 protocol=6 cksum=10eH 

saddr=135.104.25.31 daddr=135.104.25.245 
— > TCP header: sport-7000 dport-5000 scq-3266449517 ack_seq-2t 89084754 

tcp_hdr_len=5 flags=ACK 

resl-OH res2-0H window-8433 cksum-32H urgent-0 
Modified to: 

— > beginning of packet header dump «;— 

— > IP header: version=4 hdr_len=5 TOS=0 pkl_len=40 id=14S59 

frag_off-4000H TTI^255 protocol-6 cksum-lOeH 

saddr=204.7 1 .200.244 daddr=l 35. 104.25.243 
—a TCP header: sport=80 dport=1273 seq=3266449517 ack_seq=2189084733 

tcp_hdr_len-5 flags-ACK 

resl=0H res2=0H window=8433 cksum=32H urgent=0 



packet is addressed (daddr) to the IP address of the proxy 
redirector at the bogus port (dport) 5000 used by the proxy 
redirector for this TCP connection. The source IP address 
(saddr) and the source port (sport) are those of the proxy 

cache to where the GET request was directed. The ack seq 

field indicates the byte number of the first byte that is 
expected to be sent in the packet following the GET packet. 

In this example, ack seq is equal to the sequence number 

(seq) 218908427 of the GET packet plus the length of the 
GET packet, which in this case per Table 1 is 367. Thus 
ack_seq of the arriving packet is 218908754. Since client 
101-1 is unaware that a proxy redirector has increased the 



IP address and port number are those of the client. When 
received by proxy redirector 104, the packet is modified to 

5q change the source IP address and port number to the IP 
address and bogus port number of the proxy redirector. The 
destination address IP and port number are translated to thai 
of proxy cache 110-1. The sequence number (seq) is 
increased by that same value of 21 to match the byte number 

55 that the proxy cache expects to receive based on the 
sequence number previously received in the GET packet and 
the length, 367, of the GET packet 



TABLE 3 



Arriving packet: 

— > beginning of packet header dump < — 

— > IP header: vcrston-4 hdr_len-5 TOS-0 pkt_Ien-40 id-60281 
&ag_off=4000H TTL-64 protocol-a cksum-18b£H 
Baddr-135.104.2S.243 daddr-204.71.200.244 
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— > TCP header: sport=1273 dport=80 seq-2189084733 aci_seq=3266450977 
tcp_hdr_len-5 flags-ACK 

res 1=0 H res2«0H window=31856 cfcsum=d3r7H urgenl-0 
Modified to: 

— > beginning of packet header dump <••• 

--> IP header: version-4 hdr_len-5 TOS-0 pkt_len-40 id-60281 

£rag_off=4000H TTL«64 pro!ocol=fi cksum-18bfH 

saddr=135.104.25.245 daddr-135.104.25.3] 
— > TCP header: sport=5000 dport-7000 seq=2189084754 aci_seq=3266450977 

tcp_hdr_len-5 nags=ACK 

resl-OH res2-0H window-31856 cksum-d3f7H urgent-0 



received. All subsequent packets directed to the origin server 
from client 101-1 are similarly modified before being 
directed to proxy cache 110-1. 

In the above-description, it has been assumed that the 
length of the GET request both before modification, and 
after the URL extension is less than the maximum TCP 
segment size. In fact, the length of the GET request may be 
longer than one TCP segment. If the length of the GET 
request carrying the complete URL occupies x number of 
TCP segment and, after it is modified to carry the absolute 
URL, it still also fits into that same x number of TCP 
segments, then the segment carrying the URL is modified 
and overflowing characters are pipelined from one segment 
to the next. Thus, the overflowing characters from a previous 
packet are prefixed to the start of the next packet, etc., until 
the last packet, which length is increased by the increased 
number of bytes due to the URL modification. Therefore, the 
packet length of only the last segment is modified to include 
the characters that have been shifted into that segment. The 
ack_seq parameter in packets from the proxy cache to the 
client is modified starting from the acknowledgment to the 
last GET packet. 

If the modification of the URL to the absolute URL could 
cause the last TCP segment of the GET request to overflow 
to another segment, a new TCP segment would need to be 
constructed and injected by the proxy redirector. The proxy 
redirector would then need to have the capability to retrans- 
mit this segment if it was lost. Thus, the proxy redirector 
would need to have some TCP layer functionalities. In order 
to avoid adding higher level functionality to the proxy 
redirector, segment sizes are limited to less than what the 
proxy cache is actually capable of receiving. When the 
complete URL is transformed to an extended URL, the 
maximum increase in size is 22 bytes, equal to the maximum 
length of an IP address of 15 bytes plus 7 bytes from the 
prefix: http://. The client is deceived to send segments whose 
maximum size is 22 bytes less than what the protocol allows 
it to send. The TCP segment size sent by the client is 
determined by what the proxy cache, in its handshake with 
the client, indicates as the maximum segment size it can 
receive. This is indicates by the proxy cache through the 
maximum segment size (MSS) field in the ACK SYN 
packet. Accordingly, the proxy redirector 104 intercepts the 
ACK SYN packets and decreases the specified MSS amount 
by 22. For example, if the MSS specified by the proxy cache 
is 1460, it is modified to 1438 by the proxy redirector before 
being sent to the client. When the client next sends a GET 
request, the TCP segments are limited to 1438 bytes. In the 
worst case, when the client sends a GET request, 22 bytes 
will be added to the xth TCP segment that carries this 
request. The length of this xth TCP segment will still then be 
within the maximum length specified by the proxy cache. If 
the event that the proxy cache does not stipulate a maximum 



MSS in the ACK SYN packet, the default used by the client 
is 536 bytes. An MSS option is then added by the proxy 
redirector to inform the client that the maximum MSS 
expected by the other end of the TCP connection is 514 
bytes. 

As previously described, a NAT and PAT are performed 
by proxy redirector 104 on all packets addressed by client 
101-1 to an origin server, and all packets addressed by proxy 
cache 110-1 to proxy redirector 104 for return to the client. 
Proxy redirector 104 thus performs a NAT and a PAT on 
these packets flowing in both direction. If proxy redirector 
104 selects a proxy cache that is located in such a point on 
the network that packets from the proxy cache addressed 
directly to client 101-1 must pass through proxy redirector 
104 due to the network configuration, then proxy redirector 
need only perform a half-NAT on the packets flowing 
through it. Specifically, if proxy redirector 104 selects a 
proxy cache such as proxy cache 117, all packets addressed 
to client 101-1 must pass through proxy redirector 104. 
Proxy redirector 104 thus only needs to transform the 
destination IP address and port number of packets from 
client 101-1 to the IP address and port number of proxy 
cache 117, while maintaining the source IP address and port 
number as those of client 101-1. The packets returned from 
proxy cache 117 will thus be addressed to the client's IP 
address and port number. When they pass through proxy 
redirector 104, they are captured and the transformation of 
the source IP address and port to those of the origin server 
are the only address changes that need to be effected. 

The problems of the prior art with respect to persistent 
connections is obviated in accordance with the present 
invention. As previously noted, during a persistent connec- 
tion plural GET requests can be made by a client. In the prior 
art, as described, each GET request can result in a connec- 
tion from a proxy cache to a different origin server if the 
proxy cache does not have the requested objects. The ability 
of a server to maintain the state of a client's connection 
throughout the duration of the connection is compromised if 
each GET request results in connections to multiple servers. 
In accordance with the present invention, once the IP address 
of the origin server is determined at the initial DNS lookup, 
that same IP address is used by the proxy redirector as a 
prefix to each complete URL in every GET request issued by 
the client throughout the duration of the persistent connec- 
tion. Thus, assuming the proxy cache does not contain any 
of the requested objects, the proxy cache will establish a 
TCP connection to the same origin server in response to each 
GET request generated by the client. It should be noted that 
if plural client GET requests are forwarded by the proxy 
redirector to a proxy cache within a persistent TCP 
connection, ack_seq parameter in packets that flow through 
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the proxy redirector from the proxy following each GET 
request must reflect the cumulative changes effected by 
translating the complete URL to the absolute URL in each of 
the preceding GET requests within the same TCP connec- 
tion. Similarly, in all packets received by the proxy redirec- s 
tor from the client directed to the origin server within a 
persistent TCP connection, the seq parameter must reflect 
cumulative changes. 

FIGS. 3, and 4, together are flow charts detailing the 
functions of proxy redirector 104 in establishing a TCP to 
connection to a proxy cache and modifying the GET request 
so that such requests can be transparently forwarded to the 
proxy. At step 301, a SYN packet arrives from the client at 
the proxy redirector At step 302, proxy redirector selects a 
proxy cache based on a load balancing algorithm or on an is 
arbitrary or random selection. At step 303, proxy redirector 
performs a full NAT, changing the daddr from that of the 
origin server to that of the selected proxy and saddr from that 
of the client to that of the proxy redirector. At step 304 a PAT 
is performed, changing sport to that of a bogus ghost port 20 
number and dport to the proxy's port number. At step 305, 
the SYN packet is sent to the proxy. In response to that SYN 
packet, the proxy responds, at step 306, with a SYN ACK 
packet containing an MSS parameter in the TCP header. At 
step 307, a reverse translation is performed on both the IP 25 
addresses and port numbers, changing saddr and sport to 
those of the origin server and daddr and dport to those of the 
client. At step 308, the MSS field is changed by reducing the 
value of the MSS received from the proxy by 22. At step 
309, the ACK SYN packet is sent to the client. At step 310, 30 
proxy redirector receives a responsive ACK packet from the* 
client. At step 311, a full NAT and PAT are performed on that 
packet and, at step 312, the modified packet is sent to the 
proxy, thereby completing the handshake sequence. 

At step 313, a packet containing a GET request is received 35 
from the client. A full NAT is performed at step 314 and a 
PAT is performed at step 315. A determination is made at 
decision step 316 whether this is a first packet in the GET 
request. If yes, at step 317, the IP address of the origin server 
obtained Is from daddr of the arriving packet is prefixed to 40 
the complete URL in the GET request. If, at step 316, the 
packet is not a first packet in a GET request, then, at step 
318, the overflow bytes from the previous GET packet are 
prefixed to those bytes in the current packet and if the total 
number of bytes in the resultant packet is than the actual 45 
MSS sent by the proxy, the overflow bytes greater are 
buffered for prefixing to the next packet. After alternative 
steps 316 or 318, at step 319, a determination is made 
whether the current packet is the last packet of a GET 
request. If not, at step 320, the current packet is sent to the 50 
proxy and the flow returns to step 313 to receive the next 
packet in the GET request from the client. If at step 319, the 
current packet is the last packet in a GET message, then, at 
step 321, the pkt_len parameter of that packet is changed to 
reflect the change in length of the packet. At step 322, the 55 
modified packet is sent to the proxy. 

FIG. 5 illustrates the steps performed by the proxy redi- 
rector for each packet received from the proxy starting from 
the ACK to the GET request through the end of the con- 
nection. At step 501, the proxy redirector receives the ACK 60 
to the GET request, or any other packet that logically follows 
the ACK to the GET request. At step 502, reverse NAT and 
PATs are performed, translating daddr and dport to those of 
the client and saddr and sport to those of the origin server. 
At step 503, ack_seq is decreased by the amount added in 65 
the preceding GET request. At step 504, the modified packet 
is sent to the client. 
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FIG. 6 illustrates the step performed by the proxy redi- 
rector for each packet destined for the origin server from the 
client that follows the GET request. At step 601, a packet 
subsequent to the GET request is received from the client. At 
step 602, a full NAT and PAT are performed. At step 603, 
seq_no is increased by the amount of bytes added by 
modifying the previous GET request. At step 604, the packet 
is sent to the proxy. 

In the discussion above of FIGS. 3, 4, 5 and 6, it has been 
assumed that the proxy cache is located in a position such 
that packets directed to the client will not automatically flow 
through the proxy redirector. Thus, all packets from the 
proxy are addressed to the proxy redirector. Therefore, for 
packets flowing from the client, and packets flowing from 
the proxy, the proxy redirector performs a full NAT and PAT. 
If however, as previously described, the proxy cache 
selected by the proxy redirector is located on the network so 
that all packets from proxy to the client automatically flow 
through the proxy redirector, then, in the steps shown in 
FIGS. 3, 4, 5 and 6, only a half NAT needs to be performed. 

Although described in conjunction the programmable 
network element shown in FIG. 2, the proxy redirector of the 
present invention could be implemented through other 
means, using hardware, software, or a combination of both. 
As an example, a level 4 switch having a fixed program to 
perform the required packet manipulations required by the 
present invention could be used. 

As described, the proxy cache returns requested objects to 
the address from which a request originated as indicated by 
the saddr and sport parameters in the IP header information, 
which is the address of the proxy redirector 104 when the 
proxy cache is not connected on the network so that all 
responses do not automatically pass through the proxy 
redirector. The interactions between the requesting client 
and the proxy cache are transparent to both the client and the 
proxy cache, since the client does not "know" that its request 
is being redirected to the proxy by the proxy redirector, and 
the proxy cache, when receiving a GET request with an 
absolute URL does not know that thai absolute URL is not 
being formulated by the client's browser operating in a 
non-transparent mode. Advantageously, the proxy cache 
requires no software modifications and standard proxy 
caches, connected anywhere on the network can be used in 
conjunction with the proxy redirector. If, however, the proxy 
is modified, using a programmable network element as 
previously described, for example, the requested object 
retrieved by the proxy from its own cache or received from 
an origin server, can be sent directly back to the client, 
thereby obviating the need to send such packets back to the 
proxy redirector for address translations and redirection to 
the client. By performing only a half-NAT at the proxy 
redirector and leaving the client's saddr and sport as the 
source IP address and port number in the header of the SYN 
packet, GET request packet(s), and other packets forwarded 
by proxy redirector 104 from the client, the proxy cache can 
return packets responsive to the request directly to the client 
by substituting the origin server's IP address and port 
number as the source address for its own address. If the 
proxy redirector performs a full NAT and PAT, then another 
mechanism must be incorporated to provide the client 
address to the proxy cache, such as incorporating the client 
address information as part of an appendix to the absolute 
address in the modified GET request and stripping the 
appended client address information at the proxy before 
determining whether the requested object is stored in the 
cache or whether a connection to the origin server need be 
made. Advantageously, by sending the packets from the 



12/10/2003, EAST Version: 1.4.1 



US 6,389 ; 

17 

proxy cache directly back to the client, the delay encoun- 
tered by transmitting such packets back to the proxy redi- 
rector for address translation and redirection is eliminated. 
Disadvantageously, the proxy cache must be modified to 
perform these functions, precluding use of standard avail- 5 
able proxy caches. 

Although described hereinabove in connection with GET 
requests, the present invention can equally be applied to 
redirection of any type of request message in which the 
token is, for example, GET, POST or HEAD, or any other to 
type of token yet to be implemented and/or standardized. 

The foregoing therefore merely illustrates the principles 
of the invention. It will thus be appreciated that those skilled 
in the art will be able to devise various arrangements which, 
although not explicitly described or shown herein, embody is 
the principles of the invention and are included within its 
spirit and scope. Furthermore, all examples and conditional 
language recited hereinabove are principally intended 
expressly to be only for pedagogical purposes to aid the 
reader in understanding the principles of the invention and 20 
the concepts contributed by the inventors to furthering the 
art, and are to be construed as being without limitation to 
such specifically recited examples and conditions. 
Moreover, all statements hereinabove reciting principles, 
aspects, and embodiments of the invention, as well as 25 
specific examples thereof, are intended to encompass both 
structural and functional equivalents thereof. Additionally, it 
is intended that such equivalents include both currently 
known equivalents as well as equivalents developed in the 
future, i.e., any elements developed that perform the same 30 
function, regardless of structure. 

Thus, for example, it will be appreciated by those skilled 
in the art that the block diagrams and flowcharts described 
hereinabove represent conceptual views of illustrative cir- 
cuitry and processes embodying the principles of the inven- 35 
tion. Similarly, it will be appreciated that any flowcharts, 
flow diagrams, state transition diagrams, pseudocode, and 
the like represent various processes which may be substan- 
tially represented in computer readable medium and so 
executed by a computer or processor, whether or not such a 40 
computer or processor is explicitly shown. 

The functions of the various elements shown in the FIGS., 
including functional blocks labeled as "processors" may be 
provided through the use of dedicated hardware as well as 
hardware capable of executing software in association with 45 
appropriate software. When provided by a processor, the 
functions may be provided by a single dedicated processor, 
by a single shared processor, or by a plurality of individual 
processors, some of which may be shared. Moreover, 
explicit use of the term "processor" or "controller" should 50 
not be construed to refer exclusively to hardware capable of 
executing software, and may implicitly include, without 
limitation, digital signal processor (DSP) hardware, read- 
only memory (ROM) for storing software, random access 
memory (RAM), and non-volatile storage. Other hardware, 55 
conventional and/or custom, may also be included. 
Similarly, any switches shown in the FIGS, are conceptual 
only. Their function may be carried out through the opera- 
tion of program logic, through dedicated logic, through the 
interaction of program control and dedicated logic, or even 60 
manually, the particular technique being selectable by the 
imptementor as more specifically understood from the con- 
text. 

In the claims hereof any element expressed as a means for 
performing a specified function is intended to encompass 65 
any way of performing that function including, for example, 
a) a combination of circuit elements which performs that 
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function or b) software in any form, including, therefore, 
firmware, microcode or the like, combined with appropriate 
circuitry for executing that software to perform the function. 
The invention as defined by such claims resides in the fact 
that the functionalities provided by the various recited 
means are combined and brought together in the manner 
which the claims call for. Applicant thus regards any means 
which can provide those functionalities as equivalent to 
those shown hereinabove. 
What is claimed is: 

1. A method at a Layer 4 switch for redirecting an HTTP 
connection request from a client that is directed to an origin 
server to a proxy cache over a packet-based computer 
network comprising the steps of: 

receiving at least one packet containing a request message 
within the HTTP connection, the at least one packet 
having an IP header comprising a destination address of 
an origin server, the request message including a com- 
plete address of a specified object at the origin server; 

modifying, at the packet level, the request message by 
combining the destination address of the origin server 
with the complete address; and 

forwarding the at least one packet containing the modified 
request message to the proxy cache over the packet- 
based network; 

wherein the proxy cache is a standard proxy cache and, in 
the forwarding step, the at least one packet containing 
the modified request is redirected to the standard proxy 
cache transparently from the standpoints of both the 
client and the proxy cache, the proxy cache being able 
to determine whether it can satisfy the request for the 
specified object by using the combined destination 
address of the origin server and the complete address 
contained in the modified request message. 

2. The method of claim 1 wherein the step of modifying 
comprises the step of prefixing the complete address in the 
request message with the destination address of the origin 
server. 

3. The method of claim 2 further comprising the step of: 
translating the destination address in an IP header of the 

at least one packet containing the modified request 
message to the address of the proxy cache. 

4. The method of claim 3 further comprising the step of: 
translating a source address in the IP header of the at least 

one packet containing the modified request message 
from an address of the client to an address of the Layer 
4 switch. 

5. The method of claim 3 further comprising the step of: 
in a TCP header in packets received from the proxy cache 

commencing with an acknowledgment to the modified 
request message, modifying a value in an acknowl- 
edged byte sequence number field to reflect the 
increased number of bytes in the modified request 
message resulting from the step of prefixing the com- 
plete address with the destination address of the origin 
server. 

6. The method of claim 5 wherein the step of modifying 
the value in the acknowledged byte sequence number field 
comprises the step of decreasing the value in the acknowl- 
edged byte sequence number field by the number of bytes 
added by prefixing the destination address of the origin 
server to the complete address in the request message. 

7. The method of claim 6 further comprising the step of: 
translating in the IP header the destination address to the 

address of the client and the source address to that of 
the origin server in the packets received from the proxy 
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cache commencing wilh the acknowledgment to the 
request message. 

8. The method of claim 3 further comprising the step of: 
modifying a value in a sent byte sequence number field to 

reflect the increased number of bytes in the modified 5 
request message resulting from prefixing the complete 
address with the destination address of the origin server 
in a TCP header in packets received from the client 
following receipt of the request message. 

9. The method of claim 8 wherein the step of modifying 10 
the value in the sent byte sequence number field comprises 
the step of increasing the value in the sent byte sequence 
number field by the number of bytes added by prefixing the 
destination address of the origin server to the complete 
address in the request message. 

10. The method of claim 9 further comprising the step of: 15 
translating the destination address to the address of the 

proxy cache in the IP header in each packet received 
from the client following receipt of the request mes- 
sage. 

11 . The method of claim 2 further comprising, prior to the 20 
step of receiving the at least one packet containing the 
request message, the steps of: 

receiving a packet from the proxy cache indicating a 
maximum segment size that packets sent to it thereafter 2J 
should have; 

reducing by a predetermined number the maximum seg- 
ment size of packets to be thereafter sent to the proxy 
cache; and 

sending a packet to the client indicating the reduced 30 
maximum segment size that packets thereafter sent by 
the client to the origin server should have. 

12. The method of claim 11 wherein the predetermined 
number is equal at least to the maximum number of bytes 
added by the step of prefixing the destination address to the 35 
complete address in the request message. 

13. The method of claim 12 further comprising the steps 

of: 

successively shifting to a next packet in the request 
message overflow bites caused by the step of prefixing 40 
the destination address to the complete address in the 
request message, if the request message is contained 
within more than one packet; and 

changing a length-of-packet parameter in the IP header in 
a last packet of a multi-packet request message to 45 
reflect the bytes shifted into the last packet from a 
previous packet. 

14. The method of claim 12 further comprising the step of 
changing a length-of-packet parameter in the IP header to 
reflect the change in the length of that packet caused by the 50 
step of prefixing the destination address to the complete 
address in the request message, if the request message is 
contained within one packet. 

15. The method of claim 1 wherein the request message 
is a GET request. 55 

16. The method of claim of claim 1 further comprising the 
step of selecting the proxy cache from a plurality of different 
proxy caches prior to receiving the at least one packet 
containing the request message. 

17. The method of claim 1 wherein the request message 60 
is a POST request. 

18. The method of claim 1 wherein the request message 
is a HEAD request. 

19. A proxy redirector for redirecting an HTTP connection 
request from a client that is directed to an origin server to a 65 
proxy cache over a packet-based computer network com- 
prising: 
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means for receiving at least one packet containing the 
request message, the a least one packet having an IP 
header comprising a destination address of an origin 
server, the request message including a complete 
address of a specified object at the origin server, 

means for modified the request message by combining the 
destination address of the origin server with the com- 
plete address at the packet level; and 

means for forwarding the at least one packet containing 
the modified request message to the proxy cache over 
the packet-based network; 

wherein the proxy cache is a standard proxy cache and the 
means for forwarding redirects the at least one packet 
containing the modified request to the standard proxy 
cache transparently from the standpoints of both the 
client and the proxy cache, the proxy cache being able 
to determine whether it can satisfy the request for the 
specified object by using the combined destination 
address of the origin server and the complete address 
contained in the modified request message. 

20. The proxy redirector of claim 19 wherein the means 
for modifying comprises means for prefixing the complete 
address in the request message with the destination address 
of the origin server. 

21. The proxy redirector of claim 20 further comprising: 
means for translating the destination address in an IP 

header of the at least one packet containing the modi- 
fied request message to the address of the proxy cache. 

22. The proxy redirector of claim 21 further comprising: 
means for translating a source address in the IP header of 

the at least one packet containing the modified request 
message from an address of the client to an address of 
the proxy redirector. 

23. The proxy redirector of claim 21 further comprising: 
means for modifying a value in an acknowledged byte 

sequence number field in a TCP header in packets 
received from the proxy cache, commencing with an 
acknowledgment to the modified request message, to 
reflect the increased number of bytes in the modified 
request message resulting from prefixing the complete 
address with the destination address of the origin 
server. 

24. The proxy redirector of claim 23 wherein the means 
for modifying the value in the acknowledged byte sequence 
number field decreases the value in the acknowledged byte 
sequence number field by the number of bytes added by 
prefixing the destination address of the origin server to the 
complete address in the request message. 

25. The proxy redirector of claim 24 further comprising: 
means for translating in the IP header the destination 

address to the address of the client and the source 
address to that of the origin server in the packets 
received from the proxy cache commencing with the 
acknowledgment to the request message. 

26. The proxy redirector of claim 21 further comprising: 
means for modifying a value in a sent byte sequence 

number field to reflect the increased number of bytes in 
the modified request message resulting from prefixing 
the complete address with the destination address of the 
origin server in a TCP header in packets received from 
the client following receipt of the request message. 

27. The proxy redirector of claim 26 wherein the means 
for modifying the value in the sent byte sequence number 
field increases the value in the sent byte sequence number 
field by the number of bytes added by prefixing the desti- 
nation address of the origin server to the complete address 
in the request message. 
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28. The proxy redirecior of claim 27 further comprising: the modified request is redirected to the standard proxy 
means for translating the destination address to the cache transparently from the standpoints of both the 

address of the proxy cache in the IP header each packet client and the proxy cache, the proxy cache being able 

received from the client following receipt of the request to determine whether it can satisfy the request for the 

message. 5 specified object by using the combined destination 

29. The proxy redirector of claim 20 further comprising: address of the origin server and the complete address 
means for receiving a packet from the proxy cache contained in the modified request message. 

indicating a maximum segment size that packets sent to 39. The computer readable memory of claim 38 wherein 

it thereafter should have; the step of modifying comprises the step of prefixing the 

means for reducing by a predetermined number the maxi- io com Pl ete address in the request message with the destination 

mum segment size of packets to be thereafter sent to the address of the origin server. 

proxy cache; and 40. The computer readable memory of claim 39 wherein 

means for sending a packet to the client indicating the ? aid computer program instructions further comprise 

reduced maximum segment size that packets thereafter instructions defining the step of: 

sent by the client to the origin server should have. , 5 translating the destination address in an IP header of the 

30. The proxy redirector of claim 29 wherein the prede- at Ieast one packet containing the modified request 
termined number is equal at least to the maximum number message to the address of the proxy cache. 

of bytes added by the prefix of the destination address to the 41 - ^ computer readable memory of claim 40 wherein 

complete address in the request message. computer program instructions further comprise 

31. The proxy redirector of claim 30 further comprising: instructions defining the step of: 

means for successively shifting to a next packet in the 20 translating a source address in the IP header of the at least 

request message overflow bytes caused by the prefix of 0De packet containing the modified request message 

the destination address to the complete address in the from an address of the client to an address of the Layer 

request message, if the request message is contained >,''^ r ' tch ' 

within more than one packet; and , ^ com P u,er readable memory of claim 40 wherein 

„„ f „ u • i .u c i . _ 25 said computer program instructions further comprise 

means for changing a length-of-packet parameter in the IP defining the step of: P 

header in a last packet of a multi-packet request mes- : n ,Tnii,..j ■ i . • j <■ 

a . .u u . ■ . r ,. r , , ~ , , in a 1 CP header in packets received from the proxv cache 

sage to reflect the bytes shifted into he last packet from ^ „„,.• -X. i ■ j , t» u *y 

° , v commencing with an acknowledgment to the modified 

„ a ^f eV10US p3C .? ' c , . . . . request message, modifying a value in a acknowledged 

32. The proxy redirector of claim 30 wherein the proxy }Q byle S6quet]C6 number fie «j d to reflcct thc mcfe * cd 

cache further compnses means for changing a length-of- num5er of ^ in , he modifled s , ffless 

packet parameter in the IP header to reflect the change in the resulting from tn6 st of prefixmg ^ comple t c 

length of that packet caused by the prefix of the destination address with the destination address of thc ori in 

address to the complete address in the request message, if server 

the length of the request message is contained within one 3J 43 . The '^p^ readable memory of chim 42 wherein 

pa ^ el T-u . . me ste P °f modifying the value in the acknowledged byte 

33. The proxy redirector of claim 19 further comprising sequence number field comprises the step of decreasing the 
means for selecting the proxy cache from a plurality of value in me acknow i edged byte sequence number field by 
different proxy caches. m6 number of byt6S addcd by prefixj ^ destination 

34. The proxy redirector of claim 19 wheretn the means 4Q addr6SS of lhe origia server t0 the complete address in the - 
for modifying the request message is a gateway program request message 

dynamically loaded on a programmable network element. 44. ^ computer readab i 6 memory of claim 43 wherein 

35. The proxy redirector of claim 19 wherein the request said C0raput6r program instructions further comprise 
message is a GET request. instructions defining the step of: 

messa^^aTOSTre ues r i° f C ' aim " 45 translalin § in the IP header destination address to the 

L 1 reques . address of the client and the source address to that of 

37. I tie proxy redirector of claim 19 wherein the request • ,u 1 . • jr l. 

v licap. . H the ongin server in the packets received from the proxy 

message is a HEAD request. . . . , , , , r j 

10 a . • 1 1 .. . cache commencing with the acknowledgment to the 

38. A computer readable medium storing computer pro- request message 

gram instructions which are executable on a computer 5Q 45 ^ , er readab]e meffl f cIajm 

system implementing a Layer 4 switch for redirecting an said t J instna taL further comprise 

HTTP connection request from a client to a proxy cache over inslruction s defining the step of: 

a packet-based computer network, said computer program .- c ■ , • , . 

instructions comprising instructions defining the steps of: niodifying a value m a sen. byte sequence number field to 

. • . 1 . , . • • . reflect the increased number of bytes in the modified 

,h , °°! P th ^ r ^" esl 55 request message resulting from prefixing the complete 

message, the at least one packet having an IP header address wjth ^ destination addressof the origin server 

comprising a destination addressof an origin server, the in a Tcp header in kets recejved frQm ^ 

request message including a complete address of a followi K(xi of , he f m 

specified object at the origin server; 4(j ^ compu , er readab , e me Qf ^ 45 wherem 

modifying, at the packet level, the request message by 60 th e step of modifying the value in the sent byte sequence 

combining the destination address of the origin server number fie i d compr ises the step of increasing the value in 

with the complete address; and me M , byte sequence nU mber field by the number of bytes 

forwarding the at least one packet containing the modified ad ded by prefixing the destination address of the origin 

request message to the proxy cache over the packet- server to the complete address in the fequest message, 

based network; 65 47 computer readable memory of claim 46 wherein 

wherein the proxy cache is a standard proxy cache and, in said computer program instructions further comprise 

the forwarding step, the at least one packet containing instructions defining the step of: 
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translating the destination address to the address of the 
proxy cache in the IP header each packet received from 
the client following receipt of the request message. 

48. The computer readable memory of claim 39 wherein 
said computer program instructions further comprises 5 
instructions defining, prior to the step of receiving the at 
least one packet containing the request message, the steps of: 

receiving a packet from the proxy cache indicating a 
maximum segment size that packets sent to it thereafter 
should have; to 

reducing by a predetermined number the maximum seg- 
ment size of packets to be thereafter sent to the proxy 
cache; and 

sending a packet to the client indicating the reduced 
maximum segment size that packets thereafter sent by 
the client to the origin server should have. 

49. The computer readable memory of claim 48 wherein 
the predetermined number is equal at least to the maximum 
number of bytes added by the step of prefixing the destina- 2Q 
tton address to the complete address in the request message. 

50. The computer readable memory of claim 49 wherein 
said computer program instructions further comprise 
instructions defining the steps of: 

successively shifting to a next packet in the request 2 s 
message overflow bytes caused by the step of prefixing 
the destination address to the complete address in the 



request message, if the request message is contained 
within more than one packet; and 
changing a length-of-packet parameter in the IP header in 
a last packet of a multi-packet request message to 
reflect the bytes shifted into the last packet from a 
previous packet. 

51. The computer readable memory of claim 49 wherein 
said computer program instructions further comprise 
instructions defining the step of changing a length-of-packet 
parameter in the IP header to reflect the change in the length 
of that packet caused by the step of prefixing the destination 
address to the complete address in the request message, if 
the request message is contained within one packet. 

52. The computer readable memory of claim of claim 38 
wherein said computer program instructions further com- 
prise instructions defining the step of selecting the proxy 
cache from a plurality of different proxy caches prior to 
receiving the at least one packet containing the request 
message. 

53. The computer readable memory of claim 38 wherein 
the request message is a GET request. 

54. The computer readable memory of claim 38 wherein 
the request message is a POST request. 

55. The computer readable memory of claim 38 wherein 
the request message is a HEAD request. 
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(57) ABSTRACT 

A proxy cache cluster (PCC) couples to a service provider of 
a communications network to increase the availability of 
services offered by the provider to clients connected to the 
network. The clients access the services by issuing requests 
to network addresses associated with these services. The 
PCC increases the availability of the services by receiving 
and servicing those requests on behalf of the service pro- 
vider in accordance with a proxy cache clustering technique. 
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PROXY CACHE CLUSTER 

CROSS-REFERENCE TO RELATED 
APPLICATION 

This invention is related to the following copending and 
commonly assigned U.S. patent application Ser. No. 09/023, 
895 titled, Client Inherited Functionality Derived from a 
Proxy Topology where each Proxy is Independently Con- 
figured by Douglas G. Earl et al, filed on Feb. 13, 1998. 

FIELD OF THE INVENTION 

The present invention relates to services of communica- 
tions networks and, more specifically, to a system and 
method for increasing the availability of services offered by 
a service provider of a communications network. 

BACKGROUND OF THE INVENTION 

It is increasingly common for users having standalone 
computers, or computers interconnected by an institutional 
intranet or local area network, to gain access to various 
remote sites (such as those on the "World Wide Web") via 
the well-known Internet communications network. Using 
resident web browser applications executing on the 
computers, these clients may navigate among services 
("pages") stored on various servers of a service provider 
("web site") and may further request these services as 
desired. In a basic network communication arrangement, 
clients are free to access any remote web site for which 
uniform resource locators (URLs) are available. 

It is also increasingly common in network applications to 
provide the web site servers with associated proxy cache 
servers that link ("front-end") the servers with the Internet. 
A proxy cache server ("proxy") may be used to accelerate 
client access to the Internet ("forward proxy") or to accel- 
erate Internet access to a web server ("reverse proxy"). As 
for the latter reverse proxy environment, the proxy may 
access frequently requested services from the web servers 
and store ("host") them locally to effectively speed-up 
access to future requests for the services. For instance, a 
proxy may host frequently requested web pages of a web 
site. In response to a request from a browser executing on a 
client, the proxy attempts to fulfill that request from its local 
storage; if it cannot, the proxy forwards the request to a web 
site server that can satisfy the request. The web server then 
responds by transferring a stream of information to the 
proxy, which stores and forwards the information over the 
Internet onto the client. The illustrative embodiment of the 
invention described herein is applicable to a reverse proxy 
environment. 

As Internet traffic to the web site increases, the network 
infrastructure of the service provider may become strained 
attempting to keep up with the increased traffic. In order to 
satisfy such demand, the service provider may increase the 
number of network addresses for a particular service by 
providing additional web servers and/or associated proxies. 
These network addresses are typically Tranmission Control 
Protocol/Internet Protocol (TCP/IP) addresses that are rep- 
resented by URLs or wordtext (domain) names and that are 
published in a directory service, such as the well-known 
Domain Name System (DNS). Computers referred to as 
name servers implement DNS by mapping between the 
domain names and TCP/IP addressees). 

Since the proxies "front-end" the web servers (and may, 
in fact, be resident on the web servers) in a reverse proxy 
environment, the network addresses of the proxies (rather 
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than the actual web site) are generally mapped to the domain 
name of the service provider. As a result, communication 
exchanges with the proxies generally comprise IP packets or 
UDP/TCP-socketed traffic, such as socket requests and 

5 responses. A socket is essentially an interface between an 
application layer and transport layer of a protocol stack that 
enables the transport layer to identify which application it 
must communicate with in the application layer. For 
example, a socket interfaces to a TCP/IP protocol stack via 

to a set of application programming interfaces (API) consisting 
of a plurality of entry points into that stack. Applications that 
require TCP/IP connectivity typically utilize the socket API 
to interface into the TCP/IP slack. 

For a connection-oriented protocol such as TCP, the 

15 socket may be considered a session; however, for a connec- 
tionless protocol such as IP datagram using the User Data- 
gram Protocol (UDP), the socket is an entity/handle that the 
networking software (protocol stack) uses to uniquely iden- 
tify an application layer end point, typically through the use 

20 of port numbers. The software entity within the server that 
manages the communication exchanges is a TCP/IP process, 
which is schematically illustrated as layers of a typical 
Internet communications protocol stack. Protocol stacks and 
the TCP/IP reference model are well-known and are, for 

25 example, described in Computer Networks by Andrew S. 
Tanenbaum, printed by Prentice Hall PTR, Upper Saddle 
River, N.J., 1996. 

Thus to access a particular service, a client issues a 

3Q request to the domain name of the service. A name server 
receives the request, looks up the domain name and returns 
all of the mapped (proxy) associated network addresses to 
the client. The client chooses a first of the addresses directed 
to a first proxy and sends a service request to that proxy. If 
the proxy has failed and is "down", the request is ignored; 
after waiting a period of time, the client may issue another 
request to that proxy. After sending one or more non- 
responsive requests to that address, the client may issue a 
request directed to a second address of a second proxy 
associated with the service. This time the request may be 

,0 received and serviced by the second proxy. 

Subsequent requests to the particular service may be 
satisfied as the client selects each of the remaining addresses 
in, e.g., a round-robin manner, until it comes back to the first 

(J address, where a request may again be directed to the first 
proxy. As long as this proxy is down, though, requests 
directed to that first network address are ignored. In addition 
to frustrating the client, such non-responsive requests may 
prove costly to the service provider in terms of lost revenue 

;o and service down-time. As for the latter, adding a new 
service or expanding an old service of, e.g., a web server 
may be time consuming and fraught with configuration 
challenges that typically result in lengthly installations. The 
present invention is directed to alleviating such time con- 

;5 suming activities and, more specifically, to efficiently 
increasing the availability of services offered by a service 
provider. 

SUMMARY OF THE INVENTION 

60 The present invention relates to a proxy cache cluster 
(PCC) coupled to a service provider of a communications 
network to increase the availability of services offered by the 
provider to clients connected to the network. As noted, the 
clients access the services by issuing requests to network 

65 addresses associated with these services. The PCC increases 
the availability of the services by receiving and servicing 
those requests on behalf of the service provider in accor- 
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dance wilh a novel proxy cache clustering technique menls connected to a plurality of computers 120, 130, 140 

described herein. and 200. Each computer generally comprises a central 

Specifically, the PCC comprises a group of processor/ processing unit (CPU) 102, a memory 104 and an input/ 

memory mechanisms (PMMs) that ccoperately interact as a out P ul W mi1 106 interconnected by a system bus 108. 

system to host services associated with the network 5 ^ memorv 104 ma y comprise storage locations typically 

addresses. By functioning as a system of proxy cache servers com P°f d of / ™ d ° m a , cce ,? D mem ° ry devices whi ch 

defined by a common configuration of PMMs, hosted PCC are addressable by the CPU 102 and I/O unit 106. An 

services and static PCC configuration parameters, the PCC * ***** l f P™? ° f are 'VP^Y resi " 

•i u i-. jt j i <-•?: c u deDt w memory and executed by CPU, functionally orga- 

lmproves availability, performance and scalability of the ■ „ ' . • , . . . . ,■' ° 

r . ., J.J c li i i-. c m nizes the computer by, inter alia, invoking network opera- 
service provider, which preferably comprises a plurality of 10 ,.• • .<■!•.• .■ • 

u o i um c .l. • ., / . tions in support of application programs executing on the 

web servers. Scalability of the service provider may is be ^ DI , . JJ n . n r S„„ h „„ r„ t - • u 

c .. ,. . . ,j. „,„, nr ,x / CPU. An example of such an application program is a web 

H? 6r pLm V , y I J? T 5 '! ^ 1 " * browser 110 ' such as Netscape Navigator™ available from 

and/or PMM network addresses to the PCC. Ne(scape CommunicationSi 

Operationally, a designated PMM of the PCC functions as ^ Qetwork may comprise i oca i area Det works 

a coordinator to administer the common configuration by, in 145 or i „ tranelS) point-to-point links 135 and an Internet 

part, implementing a load balancing aspect of the clustering cloud 150 Collectively, the segments are interconnected by 

technique to substantially optimize assignment of the net- intermediate stations 140, such as a network switch or 

work addresses to active PMM members. Load balancing is routerj and conflgured t0 form an inl e rne twork of computers 

preferably implemented using ^characteristics of each PMM mal cornmunicate by exchanging data packets according to 

and PCC semce, such as PMM capacity PCC service load a predeflned set of protocols, such as the Transmission 

and PCC service addresses). Once the PCC is balanced , Conlrol p ro , ocol q n ternet Protocol (TCP/IP). It should be 

each PMM attends to client requests directed to its assigned noted thal other t echniques/proto6ols, such as Internet 

addressees). In the event of a failure to one of their members, Packet Exchange (IPX) protocol and the Hypertext Transfer 

the active PMMs collaborate with the PCC coordinator to Protocol (HTTp)j be advantageously used wilh the 

reassign the failed PMM s service addresses among the present invention 

remaining active members. , ,. •„ , ,• ... . ,, . . . , .„„ . 

6 In the illustrative embodiment, the internetwork 100 is 

Advantageously, the invention facilitates the addition organized in accordance with a client/server architecture 
and/or expansion of services offered by a service provider by wherein computers 120 are personal computers or work- 
dynamically balancing service loads among the existing 3Q stations configured as clients for interaction with users and 
PMM members of the PCC. That is, the proxy cache computers 130, 200 are configured as servers that perform 
clustering technique enables load balancing of the services services as directed by the clients. For example, the servers 
using the service addresses assigned to the PMM members 200 may be configured to operate as a service provider (e.g., 
rather than employing additional web servers, as in the prior a W eb site 180) as described further herein, whereas servers 
art. Moreover, the inventive clustering technique further }S 130 ma y be configured as domain name system (DNS) 
increases the availability of those services by providing servers and/or Internet provider servers. In general, the DNS 
dynamic fault detection/failover recovery in the event of servers provide the clients 120 with the network (e.g., IP) 
failure to the PMMs. address(es) of requested services in response to packets 

directed to the domain names for those services. The Internet 
40 providers, on the other hand, provide Internet access to the 

The above and further advantages of the invention may be clients via, e.g., dial-up telephone lines or cable links, 

better understood by referring to the following description in The client 120 may utilize the web browser 110 to gain 

conjunction with the accompanying drawings in which like access to the web site 180 and to navigate, view or retrieve 

reference numerals indicate identical or functionally similar services stored on the servers 200, hereinafter "web" serv- 

elements: 45 ers. In order to effectively speed-up access to the service 

FIG. 1 is a block diagram of a computer internetwork provider and reduce the retrieval time for stored services, 

including a collection of network segments connected to a each web server 200 ma y be further provided with a proxy 

plurality of client and server computers, the latter of which cache sewi. FIG. 2 is a highly schematized diagram of 

may be organized as a service provider; software components of the web server 200 including an 

FIG. 2 is a highly schematized diagram of software 50 gating system 250 having utility programs that interact 

components of the service provider server of FIG. 1; ^ vanous a PP hcatl0n P/°8 ram components to provide, 

,. . ...... , e.g., a storage interface 254 and a network interface 252, the 

FIG. 3 is a schematic block diagram of an inventive proxy , auer mMin wiln a cliem browser 110 

cache cluster (PCC) compnsing a group of processor/ over the inIernetwork 100 . ^ applicatiori program com . 

memory mechanisms (PMMs) that coopera.ely interact to 5J s inc , ude , web sefver a lica(ion 21 ^ a * d a 

host PCC services associated with network addresses of the server-application ("proxy") 220 

service provider' / — - — — - t 

' Uift§^J^iihe.proxy^O"fronl-ends"*the web server such — a 

FIG. 4 is a schematic block diagram of a PMM of the / matgnetwoTkTO 

present invention; and Swtr^fr^b'l^ 

FIG. 5 is a flowchart depicting a sequence of steps 60 4?e rdoTrJain name'Si the^rvtc^roviSerr To* access a service 

associated with a load balancing technique according to the of the'service provider 180, the client sends a request packet 

present invention. directed to the network address of a particular proxy 220 of 

DETAILED DESCRIPTION OF AN ?* Web j*?" The proxy 220 receives the request from the 

ILLUSTRATIVE EMBODIMENT „ b / OWS ? ^ clieDt *,T ™??*?.T 

65 from the web site, the proxy attempts to fulfill thai request 

FIG. 1 is a schematic block diagram of a computer locally from information stored, e.g., in memory 204 or on 

internetwork 100 comprising a collection of network seg- disk 208; in either case, the memory and/or disk function as 
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a "cache" for quickly storing and retrieving the services. If service or a file transfer protocol (FTP) proxy service; 
it cannot satisfy the request, the proxy forwards the request further examples of service types-include.Real Audio,.Real_ 
onto its web server application 210. The web server appli- Video,-NNTP-and-DNS;-andi(iii)-service type parameters 
cation then responds by transferring a stream of information thai are-unique to each service. Typical examples of con- 5 
to the proxy, which stores and forwards the information onto 5 ventional parameters run by an HTTP proxy service include^ 
the browser 110. Although the proxy 220 is shown as (a) a list of network addresses of, e.g., the web site thau 
resident on the web server 200, it should be noted that the /allows access to the-web servers, (b) whether-logging is* 
proxy may also be configured to run on a separate server ^activated, (c) the format of the activated log (common or7 

platform^ _ . — extended ) and (d) thejggjoll rate^Mbsrweb-sites-tha/ 

(! A problem arises with the arrangement described above . 1Q / provide an HTTP service run logging operations to deter- 
when the particular proxy 220 is "down" because, e.g., of a ?mine the type of requests issued by users, the kinds of errors 
failure^wilhjhcjerwrAfter repeated-attempts to access -thc—^ received by those users and the source network addresses of 
proxy are ignored the client may send a service request the requests. This latter log provides an indication of eeog- 
^^to'^to ^^rtMteT Wv frrtuoihK rapny ^ t t0> me localioas of the h f he 8 s , 
web server 200) of the web site 180; although ibis request concentration of users, 
may be serviced by the latter proxy and/or web server 15 t, . , 

application 210, the previous non-responsive requests may ^ PM L Ms OI B anized 85 a PCC in accordance with the 
prove costly to the service provider in terms of lost revenue, proxy cache clustcnn g technique that dynamically assigns 
service down-time and user frustration. The present inven- each PMM t0 lhe PCC To that end - each PMM ^ configured 
tion is directed, in part, to solving this problem. Moreover, wth a UI »q ue identifier (ID), a network address and PCC 
adding a new service or expanding an old service of the web 20 configuration software to enable participation in the clus- 
sile may be accompanied by configuration issues that result tering process. The unique ID may be the media access 
in time consuming installations. The present invention is control (MAC) address of a network interface card of the 
further directed to alleviating such time consuming activi- PMM or it may be the network address of the PMM. Once 
ties. configured and activated, the PMM "listens" for a mecha- 

In accordance with the present invention, a proxy cache 25 n ^ m notifying the PMM that it is a member of a PCC 300. 
cluster (PCC) "front-ends" the servers of a service provider According to the clustering technique, the notification 
to increase the availability of services offered by the pro- mechanism is a heartbeat message 310 that is broadcasted to 
vider. As noted, the clients access the services by issuing each member of the PCC. In the illustrative embodiment, the 
requests to network addresses associated with the services. heartbeat message 310 is effectively an "I'm (still) alive" 
The PCC increases the availability of the services by receiv- 30 message that informs the cluster members that the sender is 
ing and servicing those requests on behalf of the service a member of the cluster and (still) available. The heartbeat 
provider in accordance with a novel proxy cache clustering message may include a conventional link state packet (LSP) 
technique described herein. FIG. 3 is a schematic block mechanism 312 that allows dynamic cluster management, 
diagram of a PCC 300 comprising a cluster of processor/ As the PMM receives heartbeat messages and "learns" about 
memory mechanisms (PMMs 400) with associated network 35 other PMMs, it sends its own heartbeat message 310 to those 
connectivity that share a common configuration. The PMMs learned PMMs. 

cooperately interact as a system to host PCC services A designated PMM of the PCC functions as a PCC 

associated with network addresses of the service provider coordinator 350 to administer the common configuration 
180. In fact, the common configuration describes the PCC in and, as such, is responsible for assigning PCC service 
terms of the PMMs, static PCC configuration parameters 40 address(es) to each PMM. These service address assign- 
and hosted PCC services, which may include any service ments are contained in a message 340 that is periodically 
that is provided on the World Wide Web; an example of a distributed to the PMMs 400 by the coordinator, each PMM 
common web site service is an HTTP service. is thus aware of all its peer PMMs in the cluster. The service 

According to an aspect of the invention, a PCC service is address assignments 340 are derived from information con- 
characterized by (i) a load rating, which is a number/value 45 tained in a configuration file 345. Each message transmitted 
that reflects a measure of the PCC service's resource source by a member of the PCC, including the heartbeat 310 and 
consumption, such as the amount of traffic at the web site service address assignments 340, is identified by a PCC 
180. Notably, the actual value is not specified; just a con- Identifier or stamp 330. The stamp 330 is unique to the PCC 
sistent value to measure the resource consumption metric. and PCC configuration, and may be manifested as informa- 
Furthermore, the value is a relative value; i.e., relative to 50 tion appended to the body of a packet, or contained within 
load rating of the other services hosted by the PCC. Mea- an extended header or footer of the packet. All messages 
surement of this metric can be performed manually or via a issued by the PCC coordinator are also marked with the 
software agent that dynamically (event-driven or stamp 330 so that the recipient PMMs can be assured 
continuous) assesses the load rating. The agent may com- ("trust") that the received messages are from their coordi- 
prise conventional instrumentation software, such as a 5s nator. In an alternate embodiment, the stamp may be a digital 
simple network management protocol (SNMP) agent, or any signature when utilizing a public key cryptography system, 
other application that instruments the service to calculate its FIG. 4 is a schematic block diagram of a PMM 400. In the 
rating. Calculations are performed using normalized units of illustrative embodiment, the PMM is a personal computer or 
measurement to provide flexibility in the ratings and to workstation configured as a server according to a single 
facilitate dynamic ("on-the-fly") computer-generated 6 o processor, single memory (SPSM) model, although in an 
measurements, particularly in the event of inclusion of alternate embodiment, the PMM may comprise a multi- 
additional PMMs to a cluster in accordance with the novel processor server with or without multi-memory. In any 
clustering technique. The agent further maintains (updates) event, the PMM contains processing (processor 402), 
these generated statistics for use when balancing the hosted memory 410 and input/output (I/O 406) resources having 
services across the PCC. 65 characteristics that differ relative to other PMMs of the PCC 

The PCC service is further characterized by (ii) service but that cooperate to provide the inventive proxy cache 
type, such as an HTTP proxy service, an HTTP accelerator clustering functions. 
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According to the invention, a PMM is characterized by (i) 
capacity rating, which is number/value that reflects a mea- 
sure of the PMM's ability to provide resources. As with the 
service loading rating, the value is relative to the capacity 
rating of the other PMMs in the PCC 300 and measurement 
of this metric can be done manually or via conventional 
instrumentation software 412 (e.g., SNMP agents). Factors 
influencing the capacity rating of a PMM 400 include the 
"size" of its network connection, the "amount" of memory 
and the ' - speed" of its processor. For example, a PMM may 
have faster I/O capability than other PMMs due to its 
high-performance network interface card (NIC 408) "pipe- 
line" (e.g., 100 base T or Sonet) to heterogeneous network 
segment media (e.g., 10 Mb, 100 Mb and/or Gigabit Ether- 
net or FDDI). Another PMM may provide faster processing 
capabililes than other PMMs because it contains a high- 
performance processor 402. The relative resource charac- 
teristics of the PMMs are taken into account by the inventive 
clustering technique to produce, inter alia, the capacity 
rating. 

The PMM may also be characterized by (ii) role. The 
PMM role describes various activity states of the PMM as 
manifested in the configuration file 340 and/or by the 
heartbeat 310. For example, an active role allows the PMM 
to participate in all PCC activities, whereas a standby role 
prohibits assignments to the PMM until at least one other 
PMM is down or unusable. It should be noted that a PMM 
may be a member of more than one PCC; e.g., there may be 
2 PMMs on a low-usage service cluster and 4 PMMs on 
another high-usage service cluster. A PMM of the low-usage 
cluster may be configured into the high-usage cluster as a 
standby which means the PMM wili continue operating as a 
member of the low-usage cluster until a failure occurs in the 
high-usage cluster. At that time, the PMM will assume 
additional responsibilities for that latter cluster. The capacity 
rating of the standby PMM determines whether the machine 
may be utilized in such a role, which effectively sacrifices 
performance of the slower, low-usage service to ensure 
performance of the higher-usage service. 

In the case of the standby role, the PMM 400 transmits a 
heartbeat message 310 to inform the high-usage PCC coor- 
dinator of its availability in the event of a problem. The 
configuration file 340 specifies the roles of the member 
PMMs and their network addresses. Thus if a failure occurs, 
the PCC coordinator 350 sends a message to the standby 
PMM notifying it that it is no longer on standby, that it is an 
active member of the high-usage cluster and as to its address 
assignment(s). The configuration file is updated to reflect 
this changed role status and is distributed to all PMM 
members of the PCC. If the errant PMM comes back online, 
the PCC coordinator 350 transitions the PMM 400 back to 
the standby mode and rebalances the cluster with the errant 
PMM. The standby PMM finishes its current and pending 
work, and reverts to standby mode. It should be noted that 
multiple PMMs may assume the standby role for a PCC and 
that a PMM may be a member of multiple clusters. 
Moreover, a PMM may assume standby status on some 
clusters and active status on others. A PMM that assumes 
such a dual role distinguishes its responsibilities and com- 
munication exchanges among the various PCCs by way of 
the PCC stamp 330. 

An unusable role indicates that the PMM cannot be used 
at all by the PCC, while the down role is automatically 
assigned by the PCC coordinator upon failure to detect a 
heartbeat within the prescribed period. In particular, the 
unusable role state is used when reconfiguring or reloading 
a PMM with, e.g., new software (upgrade the clustering 
software or protocol stack). The PCC coordinator 350 marks 
the PMM unusable and rebalances the cluster. During this 
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rebalancing period, the PMM 400 finishes its work on 
requests pending in an incoming queue and then shuts itself 
down (from the point of view of being a cluster member). 
Once the PMM is reloaded, it transitions into the active state 
and, upon other members detecting its presence, the PMM 
rejoins the cluster by receiving assignments from the PCC 
coordinator. 

Note that an "administrative fault" can be created by 
changing any PMM's role status to unusable. For example, 
assume a 3-PMM cluster is moved from one location to 
another facility. Prior to moving the PCC, a first PMM is 
placed in the unusable state and proceeds to empty its 
incoming queue with pending requests, power down, move 
to the new facility, and power up. According to the inventive 
clustering technique, the PCC coordinator immediately per- 
forms the tasks of a fau It -fai lover, configuring the PMM out 
of the PCC until it is relocated and brought online. At that 
point, the PMM is placed in the active state to rejoin the 
cluster. The same procedure takes place for a second PMM. 
However when the last PMM, which is the PCC coordinator, 
is placed in the unusable role and powered down, the 
remaining two PMMs elect a new coordinator and the 
relocating procedure described above takes place. The PMM 
conveys its role status to the cluster members through the 
heartbeat message 310; e.g., presence of a heartbeat-active 
or standby roles, whereas absence of a heartbeat=unusable 
or down roles. 

The PMM 400 may be further characterized by (iii) 
primary communication address and (iv) operational status. 
The primary communication address is the network address 
on which PCC-specific communication among PMMs and 
PCC coordinator occurs; this address may be used as the 
unique ID of the PMM. The primary network address is also 
the identifier that is preferably used to elect a PCC 
coordinator, e.g., the PMM with lowest IP address. It will be 
understood to those skilled in the art, however, that other 
techniques could be used to elect a coordinator, such as use 
of a MAC address or anything that allows unique identifi- 
cation of the PMM machine. 

The operational status of a PMM includes joining, up, 
down and leaving states. A PMM assumes a joining status 
when attempting to rejoin its cluster after being offline. Once 
the PCC coordinator accepts the PMM and rebalances the 
cluster, the PMM assumes an up status. When the PMM is 
removed from the cluster, it enters a leaving status to 
gracefully bring itself to a down status. 

Table 1 illustrates an exemplary PCC configuration file 
345 containing a list of PMMs (Servers 1-3) by network (IP) 
address and a list of PCC services (Services 1-2 ). The 
configuration file also contains a list of static PCC configu- 
ration parameters and specific numbers/values associated 
with each parameter. 
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TABLE 1 



PCC configuration file 



55 



[Main] 

name»TcstOustcr 

heartBeaffimerTicks=20 

alerrTinwrTtcks-10 

joinTUneoufTiclLS-lOO 

failureSuspectedTimcTtcl£s«50 

failurcCbnfinnedTuncTicks-100 

countServerss3 

countServtces-2 

[Service 1] ; Forward Proxy 

serviceType-1 ; 1 = HTTP Proxy, 2 = HTTP Accel 

scrviceName-TcstCiustcr.Pioxy.Coin 

serviceNameAndAddiessLis 1=137.65.24^10,137.65.24.211 
port-8080 
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TABLE 1 -continued 



PCC configuration file 



loadWcight=l 

webServerPort=0 ; for accelerators only 

webServerNamcAndAddrcssList= ; for accelerators only 

commonLogEnabled»l ; 0 = oo, 1 o yes 

extendedLogEnabled-1 ; 0 - no, 1 - yes 

indexedLogEnabled^) ; 0 = no, 1 = yes 

[Service 2] ; Web Server Accelerator of www.tesl.com 

serviceTypc-2 ; 1 = HTTP proxy, 2 - HTTP accel 

port=80 

loadWeight-1 

se rv iceName=www.tes uco m 

serviceNameAndAddressList=137.65.24.220,137.65.24.221 
webServerPort=80 

webServerNameAndAddressListowww.lest.com 



commonLogEnabled-O ; 0 - no, 1 - ye 

extendedLogEnabledM} ; 0 » do, 1 = yes 

indexedLogEnabled^) ; 0 » no, 1 - yes 

[Server 1] 

serverName=Calypso 

prirnaryIPAddress-137.65.24.98 

role=l 

capacityWeight-1 
[Server 2] 

serverName=Sapphire 

primaryIPAddress-137.65.24.1]4 

ro!e=l 

capacityWeight=l 
[Server 3] 
serverName=Melout 
primaryIPAddress-137.65 .24.81 
role=2 

capacityWeight-1 
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As listed in Table 1, the static configuration parameters 
include (1) failure suspected threshold, (2) failure confirmed 
threshold, (3) join timeout interval, (4) heartbeat timer 3J 
interval and (5) alert timer interval. These parameters, which 
are described below, provide the basis of a fault-failover 
aspect of the inventive clustering technique. 

Failure suspected threshold. As noted, each PMM 400 
constantly monitors the heartbeat 310 of other PMM mem- 40 
bers of the PCC 300. If a heartbeat message from a particular 
PMM is not detected by another PMM before this threshold 
is exceeded, then failure of the particular PMM is suspected. 
At this time, each PMM actively tries to reestablish com- 
munication with the suspected PMM. Note that the LSP 45 
portion 312 of the heartbeat message 310 enables each PMM 
to maintain state information about the other PMM mem- 
bers. For example, whenever a PMM detects a heartbeat of 
another PMM member (via a recent time stamped heartbeat 
message from that member), it sets a counter indicating such 50 
heartbeat detection. The PMM periodically scans these 
states and if a heartbeat is not detected within the prescribed 
period, i.e., the failure suspect threshold, then the PMM 
transitions to a more aggressive state to confirm the sus- 
pected failure. That is, the PMM tries to actively reestablish 55 
communication by sending messages to the suspect PMM 
inquiring as to its status. 

Failure confirmed threshold. If attempts by PMM mem- 
bers to actively communicate with a suspect PMM do not 
succeed within this threshold, failure of the PMM is 60 
confirmed, the suspect PMM is effectively eliminated from 
the PCC and the PCC coordinator 350 begins redefining the 
loads of the remaining PCC members. Despite the reason for 
not responding, e.g., the PMM 400 is down, its connecting 
link is down or a port of the router into which the link is 65 
plugged is down, the suspect PMM is no longer capable of 
functioning as a member of the cluster and no longer has 



assignments from the PCC 300. Further, the PCC will not 
issue additional assignments to the suspect PMM until its 
members receive heartbeat messages from the suspect 
machine; at that time, the PCC coordinator reorganizes the 
cluster to include the now reappearing PMM. 

If the suspect PMM is the current coordinator of the PCC, 
the cluster members proceed to determine the identity of a 
new PCC coordinator. A PMM may "volunteer" to be the 
coordinator and, if others agree, it is elected as such and the 
PCC is formed. Because the configuration file 340 is readily 
available to each PMM member, the election process may be 
quickly effected by examining the file's content and deter- 
mining which remaining PMM meets the election criteria. In 
the illustrative embodiment, the PCC coordinator 350 is 
preferably the PMM 400 having the lowest IP address, 
whose role is active or standby, whose operational status is 
up or joining and who promiscuously declares, "I am the 
PCC coordinator". However, other election mechanisms are 
contemplated by the present invention. For example in 
another embodiment, the election criteria may take into 
account the capacity of each PMM or a special connectivity 
mechanism to a monitoring system. 

Join timeout interval. This interval defines a period of 
time within which a PCC waits for a PMM to join, which 
may happen either at PCC creation, PCC merge or any PCC 
reconfiguration resulting from a PMM being down. An 
interesting situation involving this interval arises when the 
PMM attempting to "join" the PCC is a nominee to become 
the PCC coordinator. For example, assume the PMM that 
would "naturally" be elected PCC coordinator, i.e., the 
PMM with the lowest IP address, cannot consistently com- 
municate with the other PCC members. Although it sent a 
message to the members inviting them to "join-up", the 
PMM thereafter does not contact the members within this 
time period. When the join timeout interval expires, the 
remaining members transition to a selection phase to elect 
another PMM as the PCC Coordinator. This prevents the 
cluster from "hanging" in a waiting mode for an extended 
period of time. 

Heartbeat timer interval. This is the frequency of the 
transmitted PCC heartbeat messages 310 which may occur, 
for example, every 50 milliseconds (msecs). If a heartbeat is 
not detected from any PMM 400 within this interval, the 
remaining PMMs transition to the failure suspect threshold 
state and proceed as described above. 

Alert timer interval. This is the frequency of a PCC alert 
timer which is generally greater than the regular heartbeat 
timer. When a PCC configuration change is pending, a PMM 
attempts to resolve the pending transaction by delivering 
cluster messages using the alert timer. PMMs transition into 
an alert mode when attempting to form a PCC; in this mode, 
they exchange messages at a faster frequency than the 
heartbeat in order to synchronize the members as the cluster 
forms. 

According to another aspect of the invention, the PCC 
coordinator 350 further administers the common configura- 
tion by implementing a load balancing aspect of the clus- 
tering technique. Load balancing substantially optimizes the 
assignment of network addresses to active PMM members 
and is preferably implemented using the relative character- 
istics of each PMM and PCC service, such as PMM capacity, 
PCC service load and PCC service addresses). Once the 
PCC is "balanced", each PMM attends to client requests 
directed to its assigned addresses. In the event of a failure to 
one of their members, the active PMMs collaborate with the 
PCC coordinator to reassign the failed PMM's network 
addresses among the remaining active members. 
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The following Examples 1-4 illustrate the inventive load 
balancing technique which is preferably implemented by the 
PCC coordinator in accordance with a sequence of steps 
depicted in the flowchart of FIG. 5. Specifically, the PCC 
coordinator executes a novel algorithm represented by the 5 
examples and flowchart to calculate these loads for the PCC 
members. In the example, the PCC comprises three (3) 
PMMs and four (4) PCC services hosted by the PMMs. The 
capacity rating of the first PMM is CaplO, the capacity 
rating of the second PMM is CaplS and the capacity rating to 
of third PMM is Cap6, whereas the load rating of each 
service is L10, L2, L20 and L10, respectively. In addition, 
there are a number of service addresses (A3, Al, A5 and A2) 
associated with each PCC service. For example, PCC Ser- 
vicel has a load rating L10 and also has 3 service addresses 15 
(A3) associated with its service; e.g., 1.1.1.1, 1.1.1.2 and 
1.1.13. 



EXAMPLE 1 
Assume the following PMMs and capacities: 



PMMl 

PMM2 

PMM3 



CaplO 
CaplS 
Cap6 



20 



25 



40 



Assume the following Services with associated load rat- 
ings and addresses 



Service! L10 A3 (1.1.1.1, 1.1.1.2, 1.1.1.3) 

Service2 L2 Al (1.1.1.4) 

Service3 L20 A5 (1.1.1.5, 1.1.1.6, 1.1.1.7, 1.1. l.S, 1.1.1.9) 

Scrvice4 L10 A2 (1.1.1.10, 1.1.1.11) 



Referring to the flowchart of FIG. 5, the load balancing 
sequence starts at Step 500 and proceeds to Step 502 where 
the loading ratings are summed. 

Sum the Service loads: 10+2+20+10-42 

In Step 504, the loading rating per address for each 
service is calculated. For example, the Servicel has three 
addresses A3, so the load rating L of 10 is divided by 3 to 
get 3.3. 

Calculate a load rating for each address for each service: 
10/3=3.3, 2/1=2, 20/5=4, 10/2=5 

In Step 506, an address list is created with the list being 
sorted, in descending order, by the load rating per address. 
For example, Service4 has two addresses A2 and a load so 
rating of L10. The service load rating for each address of 
Service4 is 5. Thus, e.g., IP service address 1.1.1.10 is 
assigned a load rating per address of 5 and service address 
1.1.1.11 is also assigned a load rating per address of 5. Note 
that an address is associated with each entry of the list. 55 

Create an address list sorted descending by load rating per 
address 

Service4, Load Rating 5, Service address 1.1.1.10 
Service4, Load Rating 5, Service address 1.1.1.11 
Service3, Load Rating 4, Service address 1.1.1.5 60 
Service3, Load Rating 4, Service address 1.1.1.6 
Service3, Load Rating 4, Service address 1.1.1.7 
Service3, Load Rating 4, Service address 1.1.1.8 
Service3, Load Rating 4, Service address 1.1.1.9 
Servicel, Load Rating 33, Service address 1.1.1.1 65 
Servicel, Load Rating 33, Service address 1.1.12 
Servicel, Load Rating 33, Service address 1.1.13 



Service2, Load Rating 2, Service address 1.1.1.4 
Step 506 thus calculates an anticipated load for each 
service address for purposes of optimally or near-optimally 
balancing the actual load across the entire cluster. In Step 
508, the capacity ratings of the PMMs are summed. 
Sum the PMM capacities: 10+15+6=31 
In Step 510, the current capacity rating for each PMM is 
calculated and normalized to a common load unit metric 
(CapacityRatingxTotalLoad)/TotalCapacity 

Calculate the current capacity rating for each PMM 
normalized in Load Units: 

(CapacityRating*TotalLoad)/TotalCapacily 
PMM1=13.5 
PMM2=20.32 
PMM3=8.13 

In Step 512, the load ratings per address are assigned by 
(i) getting the first load rating by address, (ii) assigning this 
service address to PMM with highest current capacity rating, 
(iii) reducing the current capacity rating of the PMM by the 
load rating assigned; (iv) removing the first load rating by 
address from the list; and (v) repeating Step 512 until done. 
Assign loading 

gel the first load rating by address=Service4, Load 

Rating 5, Service address 1.1.1.10 
assign this service address to the PMM with the highest 
current capacity rating 
PMM2=20.32 

PMM2 now is responsible for service address 
1.1.1.10 

reduce the current capacity rating of the PMM by the 
load assigned 
PMM2= 20.32-5=15.32 
The new PMM list becomes 

PMM1=13.5 

PMM2= 15.32 

PMM3=8.13 

remove the first load rating by address from the list 
Service4, Load Rating 5, Service address 1.1.1.11 
Service3, Load Rating 4, Service address 1.1.1.5 
Service3, Load Rating 4, Service address 1.1.1.6 
Service3, Load Rating 4, Service address 1.1.1.7 
Services, Load Rating 4, Service address 1.1.1.8 
Service3, Load Rating 4, Service address 1.1.1.9 
Servicel, Load Rating 3.3, Service address 1.1.1.1 
Servicel, Load Rating 3.3, Service address 1.1.1.2 
Servicel, Load Rating 3.3, Service address 1.1.13 
Service2, Load Rating 2, Service address 1.1.1.4 

repeat 

get the first load rating by address=Service4, Load 

Rating 5, Service address 1.1.1.11 
assign this service address to the PMM with the highest 

current capacity rating 

PMM2-15.32 

PMM2 now is responsible for service address 
1.1.1.11 

reduce the current capacity rating of the PMM by the 
load assigned 
PMM2-15.32-5-10.32 
The new PMM list becomes 

PMM1-13.5 

PMM2-10.32 

PMM3-8.13 

remove the first load rating by address from the list 
Services, Load Rating 4, Service address 1.1.1.5 
Service3, Load Rating 4, Service address 1.1.1.6 
Service3, Load Rating 4, Service address 1.1.1.7 
Service3, Load Rating 4, Service address 1.1.1.8 
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Service3, Load Rating 4, Service address 1.1.1.9 
Servicel, Load Rating 3.3, Service address 1.1.1.1 
Servicel, Load Rating 3.3, Service address 1.1.1.2 
Servicel, Load Rating 3.3, Service address 1.1.1.3 
Service2, Load Rating 2, Service address 1.1.1.4 s 
repeat 

get the first load rating by address=Service3, Load 

Rating 4, Service address 1.1.1.5 
assign this service address to the PMM with the highest 

current capacity rating 10 

PMM 1=1 3.5 

PMM1 now is responsible for service address 1.1.1.5 
reduce the current capacity rating of the PMM by the 
load assigned 

PMM1-13.5-4-9.5 15 
The new PMM list becomes 

PMM1=9.5 

PMM2=10.32 

PMM3=8.13 

remove the first load rating by address from the list 20 
Service3, Load Rating 4, Service address 1.1.1.6 
Service3, Load Rating 4, Service address 1.1.1.7 
Service3, Load Rating 4, Service address 1.1.1.8 
Service3, Load Rating 4, Service address 1.1.1.9 
Servicel, Load Rating 3.3, Service address 1.1.1.1 25 
Servicel, Load Rating 3.3, Service address 1.1.1.2 
Servicel, Load Rating 3.3, Service address 1.1.1.3 
Service2, Load Rating-2, Service address 1.1.1.4 

repeat 

get the first load rating by address=Service3, Load 30 

Rating 4, Service address 1.1.1.6 
assign this service address to the PMM with the highest 

current capacity rating 

PMM2=10.32 

PMM2 is now responsible for service address 1.1.1.6 35 
reduce the current capacity rating of the PMM by the 
load assigned 
PMM2=10.32-4=6.32 
The new PMM list becomes 

PMM1=9.5 40 

PMM2=6.32 

PMM3=8.13 

remove the first load rating by address from the list 
Service3, Load Rating 4, Service address 1.1.1.7 
Service3, Load Rating 4, Service address 1.1.1.8 45 
Service3, Load Rating 4, Service address 1.1.1.9 
Servicel, Load Rating 3.3, Service address 1.1.1.1 
Servicel, Load Rating 3.3, Service address 1.1.1.2 
Servicel, Load Rating 3.3, Service address 1.1.1.3 
Service2, Load Rating 2, Service address 1.1.1.4 50 

repeat 

get the first load rating by address-Service3, Load 

Rating 4, Service address 1.1.1.7 
assign this service address to the PMM with the highest 

current capacity rating 55 

PMM1-9.5 

PMM1 is now responsible for service address 1.1.1.7 
reduce the current capacity rating of the PMM by the 
load assigned 

PMM1-9.5-4-5.5 60 
The new PMM list becomes 

PMM1-5.5 

PMM2-6.32 

PMM3-8.13 

remove the first load rating by address from the list 65 
Service3, Load Rating 4, Service address 1.1.1.8 
Service3, Load Rating 4, Service address 1.1.1.9 



Servicel, Load Rating 3 .3, Service address 1.1.1.1 
Servicel, Load Rating 3.3, Service address 1.1. 12 
Servicel, Load Rating 3.3, Service address 1.1.13 
Service2, Load Rating 2, Service address 1.1.1.4 
repeat 

get the first load rating by address=Service3, Load 

Rating 4, Service address 1.1.1.8 
assign this service address to the PMM with the highest 

current capacity rating 

PMM3=8.13 

PMM3 is now responsible for service address 1.1.1.8 
reduce the current capacity rating of the PMM by the 
load assigned 
PMM3=8.13-4=4.13 
The new PMM list becomes 

PMM1=5.5 

PMM2=6.32 

PMM3=4.13 

remove the first load rating by address from the list 
Service3, Load Rating 4, Service address 1.1.1.9 
Servicel, Load Rating 3.3, Service address 1.1.1.1 
Servicel, Load Rating 3.3, Service address 1.1.1.2 
Servicel, Load Rating 3.3, Service address 1.1.1.3 
Service2, Load Rating 2, Service address 1.1.1.4 

repeat 

get the first load rating by address=Service3, Load 

Rating 4, Service address 1.1.1.9 
assign this service address to the PMM with the highest 

current capacity rating 

PMM2=6.32 

PMM2 is now responsible for service address 1.1.1.9 
reduce the current capacity rating of the PMM by the 
load assigned 
PMM2=6.32-4=2.32 
The new PMM list becomes 

PMM1=5.5 

PMM2=2.32 

PMM3=4.13 

remove the first load rating by address from the list 
Servicel, Load Rating 3.3, Service address 1.1.1.1 
Servicel, Load Rating 3.3, Service address 1.1.1.2 
Servicel, Load Rating 3.3, Service address 1.1.1.3 
Service2, Load Rating 2, Service address 1.1.1.4 

repeat 

get the first load rating by address=Servicel, Load 

Rating 3.3, Service address 1.1.1.1 
assign this service address to the PMM with the highest 

current capacity rating 

PMM1=5.5 

PMM1 is now responsible for service address 1.1.1.1 
reduce the current capacity rating of the PMM by the 
load assigned 
PMM 1-5.5-3.3-2.2 
The new PMM list becomes 

PMM1-2.2 

PMM2-2.32 

PMM3-4.13 

remove the first load rating by address from the list 
Servicel, Load Rating 3.3, Service address 1.1.1.2 
Servicel, Load Rating 3.3, Service address 1.1.1 J 
Service2, Load Rating 2, Service address 1.1.1.4 

repeat 

get the first load rating by address-Servicel, Load 

Rating 3.3, Service address 1.1.1.2 
assign this service address to the PMM with the highest 

current capacity rating 

PMM3-4.13 
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PMM3 is now responsible for service address 1.1.1.2 
reduce the current capacity rating of the PMM by the 
load assigned 
PMM3=4.13-3.3=0.83 

The new PMM list becomes 5 
PMM1=2.2 
PMM2=2.32 
PMM3=0.83 

remove the first load rating by address from the list 
Servicel, Load Rating 3.3, Service address 1.1.1.3 to 
Service2, Load Rating 2, Service address 1.1.1.4 

repeat 

get the first load rating by address=Servicel, Load 

Rating 3.3, Service address 1.1.1.3 
assign this service address to the PMM with the highest 15 

current capacity rating 

PMM2=2.32 

PMM2 is now responsible for service address 1.1.1.3 
reduce the current capacity rating of the PMM by the 
load assigned 20 
PMM2=2.32-3.3=-0.98 Note that negative numbers 

work without modification 
The new PMM list becomes 
PMM1=2.2 

PMM2=-0.98 25 
PMM3=0.83 

remove the first load rating by address from the list 
Service2, Load Rating 2, Service address 1.1.1.4 
repeat 

get the first load rating by address=Service2, Load 30 

Rating 2, Service address 1.1.1.4 
assign this service address to the PMM with the highest 

current capacity rating 

PMM1=2.2 

PMM1 is now responsible for service address 1.1.1.4 35 
reduce the current capacity rating of the PMM by the 
load assigned 
PMM 1=2.2-2=0.2 
The new PMM list becomes 

PMM1=0.2 40 

PMM2—0.98 

PMM3=0.83 

remove the first load rating by address from the list exit 
The resulting solution: 

PMM1 (1.1.1.5, 1.1.1.7, 1.1.1.1, 1.1.1.4) 45 
PMM2 (1.1.1.10, 1.1.1.11, 1.1.1.6, 1.1.1.9, 1.1.1.3) 
PMM3 (1.1.1.8, 1.1.1.2) 
Upon completing Step 512 by exhausting the list created 
in Step 506, the sequence ends at Step 520 with an optimal 
or near optimal balance of loads across the cluster being 50 
achieved. The PCC coordinator 350 then makes the assign- 
ments by distributing the updated configuration file 340 to 
each member. As noted, the file 340 specifies the network 
service addresses that each PMM member will respond to 
and serve. The members store the file for future reference 55 
when servicing those addresses. For example, PMM3 
receives the configuration file message indicating that it is 
assigned service addresses 1.1.1.8 and 1.1.1.2. Accordingly, 
the PMM 400 starts servicing those assigned addresses. 

It should be noted that the inventive load balancing 60 
technique may be extended to allow for other consider- 
ations. For instance, the second pass through Step 512 
results in addresses associated with the same service 
(Service4) being assigned to the same machine (PMM2). It 
may be desirable not to have two service addresses for the 65 
same service "clumped" to the same PMM. To avoid such 
clumping, the invention contemplates modification of the 



process to allow assignment of the second service address to 
the PMM with the next highest current capacity rating (e.g., 
PMM1 with the 13.5 current capacity rating). This 
modification, which is illustrated in Example 2 below, 
increases the availability of the PCC 300 so that in the event 
PMM2 fails, there will be at least one service address 
available for Service4 while the PCC reconfigures itself. It 
will be obvious to those skilled in the art that other 
modifications/loading balancing algorithms can be utilized 
to achieve the goals of improved availability, performance, 
fault failover, etc. 

EXAMPLE 2 
Assume the following PMMs and capacities: 



PMMl 

PMM2 
PMM3 



CaplO 
CaplS 
Qip6 



Assume the following Services with associated load rat- 
ings and addresses 



Servicel L10 A3 (1.1.1.1, 1.1.1.2, 1.1.1J) 

Scrvice2 12 Al (1.1.1.4) 

Service3 L20 AS (1.1.1.S, 1.1.1.6, 1.1.1.7, 1.1.1.8, 1.1.1.9) 

Service4 L10 A2 (1.1.1.10, 1.1.1.11) 



Sum the Service loads: 10+2+20+10=42 
Calculate a load rating for each address for each service: 
10/3=3.3, 2/1=2, 20/5=4,10/2=5 

Create an address list sorted descending by load rating per 
address 

Service4, Load Rating 5, Service address 1.1.1.10 
Service4, Load Rating 5, Service address 1.1.1.11 
Service3, Load Rating 4, Service address 1.1.1.5 
Service3, Load Rating 4, Service address 1.1.1.6 
Service3, Load Rating 4, Service address 1.1.1.7 
Service3, Load Rating 4, Service address 1.1.1.8 
Services, Load Rating 4, Service address 1.1.1.9 
Servicel, Load Rating 3.3, Service address 1.1.1.1 
Servicel, Load Rating 3.3, Service address 1.1.1.2 
Servicel, Load Rating 3.3, Service address 1.1.1.3 
Service2, Load Rating 2, Service address 1.1.1.4 

Sum the PMM capacities: 10+15+6=31 

Calculate the current capacity rating for each PMM 
normalized in Load Units 

(CapacityRating*TotalLoad)/ TotalCapacity 
PMM1=13.5 
PMM2=20.32 
PMM3=8.13 

Assign loading 

get the first load rating by address-Service4, Load 

Rating 5, Service address 1.1.1.10 
assign this service address to the PMM with the highest 
current capacity rating 
PMM2-20.32 

PMM2 now is responsible for service address 
1.1.1.10 

reduce the current capacity rating of the PMM by the 
load assigned 
PMM2-20.32-5-15.32 
The new PMM list becomes 
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PMM1=13.5 

PMM2=15.32 

PMM3=8.13 

remove the first load rating by address from the list 
Service4, Load Rating 5, Service address 1.1.1.11 5 
Service3, Load Rating 4, Service address 1.1.1.5 
Service3, Load Rating 4, Service address 1.1.1.6 
Service3, Load Rating 4, Service address 1.1.1.7 
Service3, Load Rating 4, Service address 1.1.1.8 
Services, Load Rating 4, Service address 1.1.1.9 
Servicel, Load Rating 3.3, Service address 1.1.1.1 
Servicel, Load Rating 3.3, Service address 1.1.1.2 
Servicel, Load Rating 3.3, Service address 1.1.1.3 
Service2, Load Rating 2, Service address 1.1.1.4 

repeat 

get the first load rating by address=Service4, Load 15 

Rating 5, Service address 1.1.1.11 
assign this service address to the PMM with the highest 

current capacity rating 

PMM2-15.32 

Since PMM2 already has a Service4 Service address, 20 

select the next highest 
PMM 1=1 3.5 

PMMl now is responsible for service address 
1.1.1.11 

reduce the current capacity rating of the PMM by the 25 
load assigned 
PMMl=13.5-5=8.5 
The new PMM list becomes 
PMM1=8.5 

PMM2=15.32 30 
PMM3=8.13 

remove the first load rating by address from the list 
Service3, Load Rating 4, Service address 1.1.1.5 
Service3, Load Rating 4, Service address 1.1.1.6 
Service3, Load Rating 4, Service address 1.1.1.7 35 
Services, Load Rating 4, Service address 1.1.1.8 
Service3, Load Rating 4, Service address 1.1.1.9 
Servicel, Load Rating 3.3, Service address 1.1.1.1 
Servicel, Load Rating 3.3, Service address 1.1.1.2 
Servicel, Load Rating 3.3, Service address 1.1.1.3 40 
Service2, Load Rating 2, Service address 1.1.1.4 

repeat 

get the first load rating by address=Service3, Load 

Rating 4, Service address 1.1.1.5 
assign this service address to the PMM with the highest 45 

current capacity rating 

PMM2= 15.32 

PMM2 now is responsible for service address 1.1.1.5 
reduce the current capacity rating of the PMM by the 
load assigned 50 
PMM2-15.32-4-11.32 
The new PMM list becomes 

PMM1-8.5 

PMM2-11.32 

PMM3-8.13 55 
remove the first load rating by address from the list 
Service3, Load Rating 4, Service address 1.1.1.6 
Services, Load Rating 4, Service address 1.1.1.7 
Service3, Load Rating 4, Service address 1.1.1.8 
Service3, Load Rating 4, Service address 1.1.1.9 60 
Servicel, Load Rating 3.3, Service address 1.1.1.1 
Servicel, Load Rating 3.3, Service address 1.1.1.2 
Servicel, Load Rating 3.3, Service address 1.1.1.3 
Service2, Load Rating 2, Service address 1.1.1.4 
repeat 65 
get the first load rating by address-Service3, Load 
Rating 4, Service address 1.1.1.6 



assign this service address to the PMM with the highest 
current capacity rating 
PMM2=11.32 

Since PMM2 already has a Service3 Service address, 

select the next highest 
PMM 1=8. 5 

PMMl now is responsible for service address 1.1.1.6 
reduce the current capacity rating of the PMM by the 
load assigned 
PMMl=8.5-4=4.5 
etc. 

A further extension to the basic load balancing technique 
is provided in Example 3 below. Referring to the flowchart 
of FIG. 5, an additional step (such as Step 514 prior to Step 
520) may include the following action: If load balancing 
with existing service address connections, then reduce the 
current capacity rating for each PMM in Step 510 by the 
loads of the service addresses already assigned, make sure 
that the loads just assigned are not in the address list, then 
proceed to step 502. The purpose of Step 514 is to rebalance 
without moving any existing assignments, even if the recon- 
figuration results in a less-optimal balance. In other words, 
the intent is to allow the PMMs to continue to properly 
service the existing connections and only '"reload balance" 
those service addresses that require redistribution because of 
the loss/failure of a PMM. This alternate embodiment of the 
inventive balancing method pertains to an established PCC 
cluster 300 with a suspect PMM that thereby necessitates 
redistribution and rebalacing of load addresses. 

EXAMPLE 3 

Assume the final configuration of PMMs and service 
addresses in Example 1. 
PMMl (1.1.1.5, 1.1.1.7, 1.1.1.1, 1.1.1.4) 
PMM2 (1.1.1.10, 1.1.1.11, 1.1.1.6, 1.1.1.9, 1.1.1.3) 
PMM3 (1.1.1.8, 1.1.1.2) 

The Service Address configuration is the same: 
Service4, Load Rating 5, Service address 1.1.1.10 
Service4, Load Rating 5, Service address 1.1.1.11 
Service3, Load Rating 4, Service address 1.1.1.5 
Service3, Load Rating 4, Service address 1.1.1.6 
Service3, Load Rating 4, Service address 1.1.1.7 
Service3, Load Rating 4, Service address 1.1.1.8 
Service3, Load Rating 4, Service address 1.1.1.9 
Servicel, Load Rating 3.3, Service address 1.1.1.1 
Servicel, Load Rating 3.3, Service address 1.1.1.2 
Servicel, Load Rating 3.3, Service address 1.1.1.3 
Service2, Load Rating 2, Service address 1.1.1.4 

The original PMM capacity configuration is the same: 
PMM1=13.5 
PMM2=20.32 
PMM3=8.13 

Assume that PMMl has gone down and a reload is 
necessary 

PMMl (1.1.1.5, 1.1.1.7, 1.1.1.1, 1.1.1.4) 
PMM2 (1.1.1.10, 1.1.1.11, 1.1.1.6, 1.1.1.9, 1.1.1.3) 
PMM3 (1.1.1.8, 1.1.1.2) 
Load Balance 

normalize the new PMM list 

Service4, Load Rating 5, Service address 1.1.1.10 
Service4, Load Rating 5, Service address 1.1.1.11 
Service3, Load Rating 4, Service address 1.1.1.5 
Service3, Load Rating 4, Service address 1.1.1.6 
Service3, Load Rating 4, Service address 1.1.1.7 
Service3, Load Rating 4, Service address 1.1.1.8 
Service3, Load Rating 4, Service address 1.1.1.9 
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Servicel, Load Rating 33, Service address 1.1.1.1 
Servicel, Load Rating 33, Service address 1.1.1.2 
Servicel, Load Rating 33, Service address 1.1.13 
Service2, Load Rating 2, Service address 1.1.1.4 



PMM2-20.32-5-5-4-4-3.3-- 0.98 



Service4, 
Service4, 
Service3, 
Service3, 
Service3, 
Service3, 
Service3, 
Servicel, 
Servicel, 
Servicel, 
Service2, 



Load Rating 
Load Rating 
Load Rating 
Load Rating 
Load Rating 
Load Rating 
Load Rating 
Load Rating 
Load Rating 
Load Rating 
Load Rating 



5, Service address 1.1.1.10 
5, Service address 1.1.1.11 
4, Service address 1.1.1.5 
4, Service address 1.1.1.6 
4, Service address 1.1.1.7 
4, Service address 1.1.1.8 
4, Service address 1.1.1.9 
33, Service address 1.1.1.1 
33, Service address 1.1.12 
33, Service address 1.1.13 
2, Service address 1.1.1.4 



PMM3=8.13-4-3.3=0.83 



20 



25 



30 



35 



The new PMM list is: 
PMM2-- 0.98 
PMM3-0.83 

Note that if the cluster of PMMs keep track of their loads 
dyamically, these computations may be done with the sta- 
tistics gathered during real-time rather than the static values. 
As well, if one or more PMMs discover that the dynamic 
loads being gathered in real-time exceed the static loads by 
some amount (e.g., a percentage) then the affected PMM 400 
may request a rebalance from the PCC Coordinator 350. 
The new Service Address list is (assignments to PMM1): 
Service3, Load Rating 4, Service address 1.1.1.5 
Service3, Load Rating 4, Service address 1.1.1.7 
Servicel, Load Rating 33, Service address 1.1.1.1 
Service2, Load Rating 2, Service address 1.1.1.4 
balance the new list 

get the first load rating by address=Service3, Load Rating 

4, Service address 1.1.1.5 
assign this service address to the PMM with the highest 40 

current capacity rating 

PMM3=0.83 

PMM3 now is responsible for service address 1.1.1.5 
reduce the current capacity rating of the PMM by the load 

assigned 45 

PMM3=0.83-4=-3.17 

The new PMM list becomes 
PMM2=-0.98 
PMM3=-3.17 
remove the first load rating by address from the list 

Service3, Load Rating 4, Service address 1.1.1.7 

Servicel, Load Rating 33, Service address 1.1.1.1 

Service2, Load Rating 2, Service address 1.1.1.4 
repeat 

get the first load rating by address Service3, Load Rating 

4, Service address 1.1.1.7 
assign this service address to the PMM with the highest 

current capacity rating 

PMM2=-0.98 

PMM2 now is responsible for service address 1.1.1.7 
reduce the current capacity rating of the PMM by the load 
assigned 

PMM2 — 0.98-4—4.98 
The new PMM list becomes 
PMM2-- 4.98 
PMM3— 3.17 



50 



55 



60 



65 



remove the first load rating by address from the list 
Servicel, Load Rating 33, Service address 1.1.1.1 
Servicel, Load Rating 33, Service address 1.1.1.2 

repeat 

get the first load rating by address-Servicel, Load Rating 

3.3, Service address 1.1.1.1 
assign this service address to the PMM with the highest 

current capacity rating 

PMM3=-3.17 

PMM3 now is responsible for service address 1.1.1.1 
reduce the current capacity rating of the PMM by the load 
assigned 

PMM3=3.17-33=-6.47 
The new PMM list becomes 
PMM2=-4.98 
PMM3=-6.47 
remove the first load rating by address from the list 
Service2, Load Rating 2, Service address 1.1.1.4 
repeat 

get the first load rating by address-Service2, Load Rating 

2, Service address 1.1.1.4 
assign this service address to the PMM with the highest 
current capacity rating 
PMM2=-4.98 
PMM2 now is responsible for service address 1.1.1.4 
reduce the current capacity rating of the PMM by the load 
assigned 

PMM2=-4.98-2=-6.98 
The new PMM list becomes 
PMM2=-6.98 
PMM3=-6.47 

exit 

The resulting solution: 

PMM2 (1.1.1.10, 1.1.1.11, 1.1.1.6, 1.1.1.9, 1.1.1.3, 

1.1.1.7, 1.1.1.4) 
PMM3 (1.1.1.8, 1.1.1.2, 1.1.1.5, 1.1.1.1) 

If a more optimal balance can be achieved because the 
results of the newly balanced configuration are "suspicious", 
e.g., the spread between PMM2 loading and PMM3 loading 
is undesirable or service addresses are "clumped", then the 
inventive technique allows choosing among one or more of 
the service addresses assigned to PMM2 and/or PMM3, 
adding them to the list of service addresses to be rebalanced 
and repeating Example 3. 

As a last example, assume that a new PMM or more PCC 
service addresses are added to a PCC 300 resulting in the 
need to rebalance. A rebalance may be tempered by the 
desire to move as few previously assigned service addresses 
as possible to prevent a temporary loss of service to clients 
using the services. 

EXAMPLE 4 

do loading as per Example 3 (with or without clumping 
prevention); 

don't commit the configuration to the PCC yet; 
for all combinations: 

take a look at spread and see if there is some movement 
of a Service Address that would improve the balance; 

check for address distribution violation (clumping); 
when all done commit to PCC. 

The goals of the examples illustrated above are to produce 
a reasonable balance of loads across the PCC while main- 
taining continuity of service, even at the expense of slight 
sub-optimal balance. 
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As noted, (he proxy cache clustering technique described 
herein provides a faull-failover mechanism for the PCC. In 
the event of a failure to a PMM 400, the PCC coordinator 
350 proceeds to rebalance the load over the remaining 
members of the PCC (Examples 1-4) and then continues 
normal operation under the rebalanced configuration. Cli- 
ents without open connections to the failed PMM function as 
though no failure event had occurred. For instance, a 
-browser 110 requesting service at an address of a PMM that 
is still "up" does not experience an interrupt in service. 
Clients with open connections to the failed PMM may, 
however, time out, retry and continue communication with- 
out further interruption. At this point, the PCC 300 and 
clients 120 have fully recovered from the fault. 

In summary, the inventive proxy cache cluster (PCC) 
cooperates with a service provider of a communications 
network to increase the availability of services offered by the 
provider to clients connected to the network. By functioning 
as a system of proxy cache servers defined by a common 
configuration of PMMs, hosted PCC services and static PCC 
configuration parameters, the PCC improves availability, 
performance and scalability of the service provider by, e.g., 
moving the network addresses serviced by a failed PMM to 
surviving PMMs of the PCC according to the inventive 
proxy cache clustering technique. 

Scalability of the service provider may be further 
achieved by adding PMMs, PCC service addresses, and/or 
PMM network addresses to the PCC. Adding PCC service 
(IP) addresses means, for instance, adding a new HTTP 
service address, whereas adding PMM network (IP) 
addresses means adding a new PMM which has a network 
address. It should be noted that a situation where scaling 
does not benefit by the addition of a PMM is when there are 
fewer PCC service addresses than PMMs. A service address 
can not be split across a PMM, thus the minimum configu- 
ration is a one-to-one relationship between PMMs and PCC 
service addresses. Although there may be situations where 
additional PMMs may outnumber the service addresses in a 
PCC, the only use for these "spare" PMMs is for failover in 
the event of a faulty PMM. 

The minimum configuration of the PCC preferably com- 
prises at least two PMMs, although there is no architectural 
limit to the number of PMMs that can be assigned to a PCC. 
The minimum configuration does not lend itself to load 
balancing in the event of one PMM failing, but if a failure 
occurs, there is automatic fail-over to the surviving PMM. 
More than two PMMs is desirable because load balancing 
can be performed in the event of a failure. In addition, the 
illustrative configuration of the service provider/web site 
includes a plurality of web servers 200, each having a PMM 
resident thereon. Collectively, the PMMs function as front- 
end entities to "float" all of the network addresses of the 
service provider 180. Thus if one of the web servers 200 fails 
or otherwise goes down, its network address is reassigned 
other PMMs, as described herein. 

While there has been shown and described an illustrative 
embodiment for increasing the availability of services 
offered by a service provider to clients connected to a 
communications internetwork in accordance with an inven- 
tive proxy cache clustering technique, it is to be understood 
that various other adaptations and modifications may be 
made within the spirit and scope of the invention. For 
example, according to another aspect of the invention, the 
novel clustering technique provides fault-failover partition- 
ing of a PCC. A desirable artifact of the invention is that a 
single PCC may split into more than one PCC. If certain 
members of the PCC lose contact with the rest of the PCC 
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members, the portion of the PCC that does not have a PCC 
coordinator proceeds to elect a new PCC coordinator and 
form a new PCC. The PCC with the original PCC coordi- 
nator then load balances across the remaining PMMs and 
continues servicing assigned addresses. This activity occurs 
despite the number of fragments that a PCC may be parti- 
tioned into. 

In yet another aspect of the present invention, fault- 
correction partition merging is provided by the invention. 
Continuing with the example above, assume the lost portion 
of the PCC resumes contact with the rest of the PCC 
members and attempts to rejoin the cluster. An immediate 
concern is which PCC coordinator becomes the coordinator 
of the reformed PCC. The invention contemplates determin- 
ing the busiest cluster and, thereafter, not disturb it so as to 
minimize perturbation to service. According to an embodi- 
ment of the invention, the busiest cluster is determined by 
examining a most recent service interval (contained in the 
heartbeat message 310) and the PCC coordinator with the 
lowest interval becomes the new coordinator. 

A service interval is the interval between the last service 
request and the current service request, e.g., from a browser 
110 to a web site 180. The PCC coordinator with the lowest 
service interval (e.g., 30 ms vs. 500 ms) is assumed to be 
servicing more traffic so, according to this embodiment, it is 
elected the new coordinator. Note that other metrics can also 
be used to determine the new coordinator. The losing 
coordinator then broadcasts a shutdown restart message to 
all members of the losing cluster. The new coordinator 
proceeds to integrate the new PMMs by load balancing 
according to the clustering technique described herein. The 
shutdown restart message instructs the PMMs to finish their 
current work and then transition into a joining mode. The 
surviving PCC coordinator then balances across those 
PMMs that are joined. 

The foregoing description has been directed to specific 
embodiments of this invention. It will be apparent, however, 
that other variations and modifications may be made to the 
described embodiments, with the attainment of some or all 
of their advantages. Therefore, it is the" object of the 
appended claims to cover all such variations and modifica- 
tions as come within the true spirit and scope of the 
invention. 

What is claimed is: 

1. A method for increasing the availability of services 
offered by a service provider to clients connected to a 
communications network, the clients accessing the services 
by issuing requests to service addresses associated with 
these services, the method comprising the steps of: 

providing a plurality of processor/memory mechanisms 
(PMMs) adapted to cooperatively interact in order to 
receive and service the requests on behalf of the service 
provider; 

organizing the PMMs as one or more proxy cache clusters 
(PPCs) by dynamically assigning each PMM to one or 
more PCCs; 

balancing the service addresses among PMMs by assign- 
ing selected service addresses to each PMM of the 
PCC; and 

rebalancing the service addresses among PMMs of the 
PCC in response to dynamic changes in the PCC. 

2. The method of claim 1 wherein the step of organizing 
comprises the step of configuring each PMM with a unique 
identifier (ID), a network address and PCC configuration 
software. 

3. The method of claim 2 wherein the step of organizing 
further comprises the step of notifying each PMM of avail- 
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ability in ihe PCC using a heartbeat message broadcasted to 
each member of the PCC. 

4. The method of claim 3 wherein the step of organizing 
further comprises the step of sharing a common configura- 
tion among the PMMs that describes the PCC in terms of the 5 
PMMs, static PCC configuration parameters and hosted 
PCC services. 

. 5. The method of claim 4 wherein the step of sharing a 
common configuration comprises Ihe step of characterizing 
each hosted PCC service by a load rating value that reflects to 
a measure of the PCC service's resource consumption. 

6. The method of claim 4 wherein the step of sharing a 
common configuration comprises the step of characterizing 
the hosted PCC services by service type. 

7. The method of claim 6 wherein the service type 15 
comprises one of a Hypertext Transfer Protocol (HTTP) 
proxy service, an HTTP accelerator service, a file transfer 
protocol proxy service, real audio and real video. 

8. The method of claim 4 wherein the step of sharing a 
common configuration comprises the step of characterizing 
the hosted PCC services by service type parameters that are 
unique to each service. 

9. The method of claim 5 wherein the step of providing 
comprises the step of characterizing each PMM by a capac- 
ity rating value that reflects a measure of the PMM's ability 
to provide resources. 

10. The method of claim 1 wherein the step of balancing 
the service addresses comprises the step of designating a 
particular PMM to function as a PCC coordinator to assign 
the service addresses to the PMMs. 

11. The method of claim 10 wherein the step of balancing 
the service addresses further comprises the step of periodi- 
cally distributing a message containing the service address 
assignments from the PCC coordinator to the PMMs. 

12. The method of claim 11 wherein the step of periodi- 
cally distributing comprises the step of uniquely identifying 
the service address assignment message as issued by the 
PCC coordinator by marking the message with a stamp. 

13. The method of claim 11 wherein the step of providing 
comprises the step of characterizing each PMM by a role 
that describes various activities of the PMM as manifested 
in one of the service address assignment message and the 
heartbeat message. 

14. The method of claim 13 wherein the role comprises an 
active role in one or more PCCs that allows the PMM to 
participate in all PCC activities. 

15. The method of claim 13 wherein the role comprises an 
standby role in one or more PCCs that prohibits assignments 
to the PMM until at least one other PMM in the PCC 
assumes one of a down or unusable role. 

16. The method of claim 15 wherein the unusable role 
indicates that the PMM cannot be used by the PCC, whereas 
the down role is automatically assigned by the PCC coor- 
dinator upon failure to detect a heartbeat message within a 
predetermined period. 55 

17. The method of claim 13 wherein the role comprises an 
active role in one or more PCCs that allows the PMM to 
participate in all PCC activities and a standby role in one or 
more PCCs that prohibits assignments to the PMM until at 
least one other PMM in the PCC assumes one of a down or 60 
unusable role. 

18. The method of claim 10 wherein the step of providing 
comprises the step of characterizing each PMM by a primary 
communication network address for communicating among 
the PMMs and the PCC coordinator. 65 

19. The method of claim 18 wherein the primary com- 
munication network address is the unique ID of the PMM. 
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20. The method of claim 1 wherein the step of providing 
comprises the step of characterizing each PMM by an 
operational status including one of a joining status when the 
PMM attempts to rejoin the PCC after being offline, an up 
status after the PCC coordinator accepts the PMM and 
rebalances the PCC, a leaving status when the PMM 
becomes unavailable to the PCC and a down status after the 
PMM is unavailable to the PCC. 

21. The method of claim 1 wherein the step of balancing 
comprises the steps of: 

summing the load ratings of the hosted PCC services; 
calculating the load rating per address for each hosted 
PCC service; 

creating an address list that is sorted, in decending order, 

by the calculated load rating per address; 
summing the capacity ratings of Ihe PMMs; and 
calculating a current capacity rating of each PMM nor- 
malized to a common load unit metric. 

22. The method of claim 1 wherein dynamic changes in 
the PCC comprises addition or deletion of services. 

23. The method of claim 1 wherein dynamic changes in 
the PCC comprises real-time collection of load data. 

24. The method of claim 1 wherein dynamic changes in 
the PCC comprises failure of a PMM. 

25. The method of claim 1 wherein the step of rebalancing 
comprises the steps of: 

summing the load ratings of the hosted PCC services; 
calculating the load rating per address for each hosted 
PCC service; 

creating an address list that is sorted, in decending order, 

by the calculated load rating per address; 
summing the capacity ratings of the PMMs; and 
calculating a current capacity rating of each PMM nor- 
malized to a common load unit metric. 

26. The method of claim 1 wherein the step of organizing 
comprises the step of dynamically establishing one or more 
new clusters that continue to service clients if one or more 
PMMs loses contact with their original clusters. 

27. A computer-readable medium comprising: instruc- 
tions and data written thereon, said instructions and data 
containing information for the practice of the method of the 
claim 1. 

28. Electromagnetic signals traveling over a computer 
network comprising: said electromagnetic signals carrying 
information for the practice of the method of claim 1. 

29. A system for increasing the availability of services 
offered by a service provider to clients connected to a 
communications network, the clients accessing the services 
by issuing requests to network addresses associated with 
these services, the system comprising: 

a plurality of processor/memory mechanisms (PMMs) 
cooperatively interacting to receive and service the 
requests on behalf of the service provider, each PMM 
characterized by a primary communication address and 
assigned at least one network address to service; 

means for organizing the PMMs as one or more proxy 
cache clusters (PPCs) by dynamically assigning each 
PMM to one or more PCCs; and 

means for balancing service addresses among PMMs by 
assigning selected service addresses to each PMM of 
the PCC 

means for rebalancing service addresses among PMMs of 
the PCC in response to dynamic changes in the PCC. 
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